Type alias in C#

  • Thread starter peter.tornqvist
  • Start date
D

Dave Sexton

Hi Dustin,

Ok, so ILASM also prevents the declaration of methods on enums, but does that
change the definition of structure from being "any object that can be
allocated on the stack"?

Admittedly, I have no formal definition to cite. I've inferred the meaning of
the term "structure" from experience using .NET and its use in MSDN
documentation, which I've cited already.

I'm waiting on Chris to supply evidence to the contrary (within the scope of
managed programming, I might add).

--
Dave Sexton

Dustin Campbell said:
I've been trying to stay away from C# here, and just discuss whether
all value-types are structures (although I have been referring to them
as structs from time to time, which as I said in a related post might
have been a bit misleading - but it's habit). I believe that you can
derive from System.Enum and add methods or implement interfaces in
CIL, so your point doesn't hold true on a framework level (as opposed
to just C#). Please correct me if I'm wrong.

That's incorrect. This will fail to assemble:

.assembly extern mscorlib { auto }
.assembly FruitTest { }
.module FruitTest.exe

.class public auto ansi sealed Fruit
extends [mscorlib]System.Enum
{
.field public specialname int32 __value
.field public static literal valuetype Fruit Banana = int32(1)
.field public static literal valuetype Fruit Apple = int32(2)
.field public static literal valuetype Fruit Orange = int32(3)
.method public int32 GetIndex() cil managed
{
ldfld int32 Fruit::__value
ret
}
}

The error is "error -- Method in enum".

So, clearly, enumerations are *not* structures because they lack all but one
of the features of a structure.

Best Regards,
Dustin Campbell
Developer Express Inc.
 
B

Ben Voigt

Dave Sexton said:
Hi Dustin,

Ok, so ILASM also prevents the declaration of methods on enums, but does
that change the definition of structure from being "any object that can be
allocated on the stack"?

That could be used as a working definition of "value type", but not
"structure", as everyone else here has been explaining.
Admittedly, I have no formal definition to cite. I've inferred the
meaning of the term "structure" from experience using .NET and its use in
MSDN documentation, which I've cited already.

I'm waiting on Chris to supply evidence to the contrary (within the scope
of managed programming, I might add).

--
Dave Sexton

Dustin Campbell said:
I've been trying to stay away from C# here, and just discuss whether
all value-types are structures (although I have been referring to them
as structs from time to time, which as I said in a related post might
have been a bit misleading - but it's habit). I believe that you can
derive from System.Enum and add methods or implement interfaces in
CIL, so your point doesn't hold true on a framework level (as opposed
to just C#). Please correct me if I'm wrong.

That's incorrect. This will fail to assemble:

.assembly extern mscorlib { auto }
.assembly FruitTest { }
.module FruitTest.exe

.class public auto ansi sealed Fruit
extends [mscorlib]System.Enum
{
.field public specialname int32 __value
.field public static literal valuetype Fruit Banana = int32(1)
.field public static literal valuetype Fruit Apple = int32(2)
.field public static literal valuetype Fruit Orange = int32(3)
.method public int32 GetIndex() cil managed
{
ldfld int32 Fruit::__value
ret
}
}

The error is "error -- Method in enum".

So, clearly, enumerations are *not* structures because they lack all but
one of the features of a structure.

Best Regards,
Dustin Campbell
Developer Express Inc.
 
C

Christopher Ireland

Dave Sexton said:
Hi Chris,


No, because replacing what I wrote (and meant) with your own terms
wouldn't make my point any clearer :)

So when you talk about 'structures' you are referring to the
System.ValueType class? If so, then we're there :)

Chris.
 
C

Christopher Ireland

Hi Dave,
I'm waiting on Chris to supply evidence to the contrary (within the scope
of managed programming, I might add).

Here it is (for what it's worth):
http://msdn2.microsoft.com/en-us/library/c83eyewf(VS.80).aspx
(scroll down to 'structure')

"structure
A user-defined value type. Like a class, structures can contain
constructors, constants, fields, methods, properties, indexers, operators,
and nested types. Unlike classes, however, structures do not support
inheritance. See also: class, field, indexer, nested type, property, value
type."

The key here is 'user-defined', stated explicity to distance the meaning
from 'built in', possibly.

Chris.
 
D

Dave Sexton

Hi Chris,

Interesting, thanks. However, that means either that definition is wrong or
the docs that state System.Enum and all the FCL primitives are structures is
wrong :)

Also, I've heard many people refer to structure as I've defined it. I guess
you haven't.

Because of that definition there is some ambiguity in the term now, however
I'm still not sure that one small paragraph should invalidate the use of the
term throughout the FCL documentation. Do you?
 
D

Dave Sexton

Hi Ben,
That could be used as a working definition of "value type", but not
"structure", as everyone else here has been explaining.

No, you were trying to explain how that's true for the C# keyword, "struct",
which is different than the term "structure". But even the keyword, "struct"
is used to represent types that derive from System.ValueType for the C#
compiler, so they share common ground. "enum" is purely a compiler term used
to make declaring Enums easier and has no bearing on this discussion.

I've determined that the term "structure" represents value-types based on how
the term is used in MSDN docs and other managed information that I've read,
and from experience working with other professionals that use the term the
same. I've supplied evidence of this. Chris has supplied evidence to the
contrary, however I don't think it's enough yet to entirely invalidate the use
of the term throughout MSDN, at the very least.

Value-types (types that derive from System.ValueType), allow for memory
allocation in-line, which may very well be on the stack.

Therefore, if the term "structure" may be used to refer to types that derive
from ValueType [MSDN docs], and all ValueTypes may be allocated on the stack,
then the definition I supplied appears to be one in the same:

Structures are value-types; any object that can be allocated on the stack.

C# "structs" are structures.

C# "enums" are Enums, which are structures as well, but certainly aren't
"structs". However, nobody meant that they were.
Not all value types are structures, for example, enum.

I think I've proven otherwise if you consider MSDNs use of the term.
 
C

Christopher Ireland

Hello Dave,
Because of that definition there is some ambiguity in the term now,
however I'm still not sure that one small paragraph should invalidate the
use of the term throughout the FCL documentation. Do you?

I've no idea. I guess the major advantage of computational languages over
natural languages are that they are less ambiguous. As far as the code goes,
we both know that the c# struct and c# enum are value types but only one of
them is a struct. Referring to value types as structures could lead to
confusion when others refer to c# struct(s) as structures, as I did.

Chris.
 
C

Christopher Ireland

Hello Dave,
I think I've proven otherwise if you consider MSDNs use of the term.

For the record, in my phrase above when I said 'structures' I was referring
to 'c# struct'(s). Sorry for any confusion this may have caused.

Chris.
 
D

Dave Sexton

Hi Chris,

Understood - I believe that I inappropriately used the term "struct" when
referring to "structure" in some cases.

And BTW, I believe that the definition of "structure" that you cited should
really be the definition of the C# keyword "struct". Don't you agree?
 
D

Dave Sexton

Hi Chris,

Agreed.

--
Dave Sexton

Christopher Ireland said:
Hello Dave,


I've no idea. I guess the major advantage of computational languages over
natural languages are that they are less ambiguous. As far as the code goes,
we both know that the c# struct and c# enum are value types but only one of
them is a struct. Referring to value types as structures could lead to
confusion when others refer to c# struct(s) as structures, as I did.

Chris.
 
M

Marc Gravell

Good grief!

To recap, I was the original user of sloppy semantics in this chain:

MG> ...it won't work with interface, static, sealed, struct...
CI> ...It also won't work with value types...
MG> ...Hence "struct" in that list...

OK people, that was a slightly lazy bit of terminology! I used "struct"
(a C# keyword) interchangeably with "ValueType" (a CLR concept). Oops!
It seems to have been a catalyst for some faily lively debate, though,
so maybe it wasn't such a bad thing! If only I had said "structure"...
although that too seems up for debate here.

But
 
D

Dustin Campbell

Understood - I believe that I inappropriately used the term "struct"
when referring to "structure" in some cases.

Of course, VB *does* use the term "Structure" to refer to the same kind of
type as a C# "struct".

Best Regards,
Dustin Campbell
Developer Express Inc.
 
D

Dustin Campbell

Interesting, thanks. However, that means either that definition is
wrong or the docs that state System.Enum and all the FCL primitives
are structures is wrong :)

In the case of System.Enum, I think that System.Enum *is* a structure. However,
IMO, the jury is still out on whether types that derive from System.Enum are.

Best Regards,
Dustin Campbell
Developer Express Inc.
 
D

Dustin Campbell

Because of that definition there is some ambiguity in the term now,
however I'm still not sure that one small paragraph should invalidate
the use of the term throughout the FCL documentation. Do you?

I think that referring to this as "one small paragraph" is quite an understatement.
I mean, if you can't trust the definition in the *glossary*, what can you
trust?

Best Regards,
Dustin Campbell
Developer Express Inc
 
C

Christopher Ireland

Dave Sexton wrote:
| Hi Chris,
|
| Understood - I believe that I inappropriately used the term "struct"
| when referring to "structure" in some cases.
|
| And BTW, I believe that the definition of "structure" that you cited
| should really be the definition of the C# keyword "struct". Don't
| you agree?

Yes, I do. Instead of saying "not all value types are structures" I should
have said "not all value types are C# struct(s)"
 
D

Dave Sexton

Hi Dustin,
I think that referring to this as "one small paragraph" is quite an
understatement. I mean, if you can't trust the definition in the *glossary*,
what can you trust?

Good point :)

I trust the fact that every document in the MSDN library for all FCL
ValueTypes (of course, I haven't verified ALL) explicitly state each as
"Structure" in their titles. The MSDN documentation for System.ValueType uses
the term "structure" as well.

Interestingly enough, I searched the C# glossary, "struct" keyword definition
and some programming guidance documentation (all C#) but none contained the
term "structure" in any related way. (It's used to describe a "data
structure" though).

In VB.NET, as you mentioned in another post in this thread, the term
"Structure" appears to mean value-type. It's used for constraining generic
arguments. You have the choice of "Class", "Structure" or neither keyword in
VB.NET. In C#, "class", "struct" or neither keyword may be used to constrain
generic arguments after the "where" statement.

If you use the C# keyword "struct" to constrain a generic argument you can
successfully pass in an enum value:

public enum AnEnum { A, B }

class Program
{
static void Test<T>(T value)
where T : struct
{
Console.WriteLine("Testing: " + value.ToString());
}

static void Main(string[] args)
{
Test<int>(5);
Test<AnEnum>(AnEnum.B);

Console.WriteLine("Done");
Console.ReadLine();
}
}

Output:

Testing: 5
Testing: B
Done

So, it seems that even the C# compiler will treat types derived from Enum as
structs. The C# "enum" keyword was really the only thing preventing me from
thinking that "structure" was the same as "struct". But now it's obvious to
me that the "enum" keyword simply replaces "struct", providing a more specific
way (and only way) of declaring enums in the C# language.

I believe now that "enum" (C#) is a more-derived concept, but still describes
a "struct". Since all "structs" are "value-types", including "enums", and
since the term "structure" refers to all ValueTypes as well [MSDN docs], I
must conclude that the term "structure" is equal to "struct" and that "enum"
can be referred to as "enum", "struct", or "structure", in the same way that
"XmlDocument" may be referred to as "object". The term "structure", I think
of as a language-agnostic way to describe a value-type. The term "struct",
when used outside of a C# context can be used interchangeably with
"structure", since they mean the same thing. In a context that deals with the
C# compiler directly, I'll try to refrain from using "structure" as it
obviously has no place within the C# language itself. When speaking of the
VB.NET compiler it may be used freely because it apparently means the same
thing as the C# "struct" keyword.

The glossary needs to be updated ;)

I don't think that in the context of this thread the term "struct" was misused
by anyone, including Mark, who claims to have been the first to misuse the
term. Anytime "struct" or "structure" was used, IIRC, value-type was "meant",
and that seems now to have been just fine.
 
D

Dustin Campbell

Hi Dustin,
Good point :)

I trust the fact that every document in the MSDN library for all FCL
ValueTypes (of course, I haven't verified ALL) explicitly state each
as "Structure" in their titles.

Except that all FCL enumerations (which are also ValueTypes) list "Enumeration"
in their titles. Since enumerations are ValueTypes, that statement isn't
really correct. So, why does your logic for the presence of the keyword "Structure"
not apply to the presence of the keyword "Enumeration" as well? It seems
like you are trying to use this title keyword to prove your point but it
really seems to prove mine -- that enumerations are not "structures".
Interestingly enough, I searched the C# glossary, "struct" keyword
definition and some programming guidance documentation (all C#) but
none contained the term "structure" in any related way. (It's used to
describe a "data structure" though).

In VB.NET, as you mentioned in another post in this thread, the term
"Structure" appears to mean value-type. It's used for constraining
generic arguments. You have the choice of "Class", "Structure" or
neither keyword in VB.NET. In C#, "class", "struct" or neither
keyword may be used to constrain generic arguments after the "where"
statement.

If you use the C# keyword "struct" to constrain a generic argument you
can successfully pass in an enum value:

That indeed is a good point but that constraint is really only ensuring that
a type argument will descend from System.ValueType -- not that it is a C#
struct. So, its use on enumerations could simply be considered a side effect.

I just can't understand how an enum can be considered a structure when it
only shares one feature of structures: stack allocation. Other features such
as interface implementation and method declaration are not supported on enums.
And, using your own argument, the MSDN documentation never refers to an enumeration
as a "structure". Therefore, I have to conclude that enums *are* different
from structs. They are different kind of entity that are also allocated on
the stack. Of course, I'd really *like* to see Microsoft make enumerations
more like standard structures. It seems to me that it would be extremely
useful to have instances methods and interface support for enum types.

Best Regards,
Dustin Campbell
Developer Express Inc.
 
D

Dave Sexton

Hi Dustin,
Except that all FCL enumerations (which are also ValueTypes) list
"Enumeration" in their titles. Since enumerations are ValueTypes, that
statement isn't really correct. So, why does your logic for the presence of
the keyword "Structure" not apply to the presence of the keyword
"Enumeration" as well? It seems like you are trying to use this title
keyword to prove your point but it really seems to prove mine -- that
enumerations are not "structures".

I see enums as restricted structures, but structures nonetheless because they
inherit from System.Enum, which is a structure.

The fact that the docs for FCL enumerations don't have "Structure" in their
titles is because, IMO, it would be redundant to write "DayOfWeek Enumeration
Structure", for example. I don't believe the lack of the term "structure" in
the titles proves anything. My proof is based on the presence of the term,
not its absence.
That indeed is a good point but that constraint is really only ensuring that
a type argument will descend from System.ValueType -- not that it is a C#
struct. So, its use on enumerations could simply be considered a side
effect.

I don't think so. They could have easily used the keyword "enum", or the
keyword "value" to represent all value-types. I believe they didn't because
it's natural to think of enums as structs, although in terms of the C#
compiler and defining structures the literal meaning of "struct" doesn't
represent the literal meaning of "enum". These terms are obviously
overloaded, so depending on the context in which they are used they may or may
not be interchangeable.
I just can't understand how an enum can be considered a structure when it
only shares one feature of structures: stack allocation. Other features such
as interface implementation and method declaration are not supported on
enums.

Well it shares more than one feature through inheritance, including stack
allocation.

Enum-derived types inherit the GetHashCode and Equals implementations, as
wells as operator overloads (I assume) that are all part of the "structure" on
which Enums are based (provided by System.ValueType).

I don't believe that the limitations imposed on enums, after inheritance,
takes anything away from their derived nature. They behave like structs, and
you can use them like structs as parameters. You can even cast them down to
ValueType and use them as such. As a matter of fact, I've created library
methods that take System.Enum as a parameter. So, at what point does the
"structure" that I'm accepting as a parameter become "not" a structure? Even
a ValueType, for instance, is still technically an "object".
And, using your own argument, the MSDN documentation never refers to an
enumeration as a "structure". Therefore, I have to conclude that enums *are*
different from structs.

Again, my argument doesn't depend on the absence of any keywords, but their
presence. Presence has a lot more weight :)

The DayOfWeek Enumeration documentation, for example, doesn't mention anything
about it being a "value-type" or an "object" either.
They are different kind of entity that are also allocated on the stack. Of
course, I'd really *like* to see Microsoft make enumerations more like
standard structures. It seems to me that it would be extremely useful to
have instances methods and interface support for enum types.

Jon Skeet had proposed something he calls "class enums" that you might be
interested in reading (if you haven't already :)

"Enhanced Enums in C#"
http://msmvps.com/blogs/jon.skeet/archive/2006/01/05/classenum.aspx
 
D

Dave Sexton

Hi Dustin,

Thanks for the discussion, it has been informative.

I'll take a look at your article when I get a chance to read it thoroughly.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top