Type alias in C#

[Dave Sexton]

Hi Dustin,

Thanks for the input, but I don't think this is simply a debate on semantics.
But just to address that concern, I do think that all value-types can be
considered structs. The term "structure" was not coined in C#.

"Data types are separated into value types and reference types. Value types
are either stack-allocated or allocated inline in a structure"

"ValueType Class"
[link in related post]

System.Enum is also documented as a "structure" (see link in related post).

The CLR only "seeing" classes is irrelevant. The fact of the matter is, any
object that derives from ValueType can be considered a structure. Any object
that doesn't, can't.

 

[Dave Sexton]

Hi Chris,

I don't suppose you know why the System.Type class has an IsEnum property
and not an IsDouble (or IsAnyOtherValueType) property? I am aware that it
has an IsValueType property. Why would enums need to be treated differently?

Probably because you can derive from them, which is uncommon for structs

 

[Christopher Ireland]

Hello Dave,

I wasn't referring to polymorphism at all. But now that you mention it,
how is derivation different from inheritance? I always thought they were
the same

Mmm, the docs do make that distinction. In the docs for 'Structs' is says:
"All value types in C# inherently derive from ValueType, which inherits from
Object."

As Dustin points out, I guess this is an artefact of C#'s implementation of
the CLI; if structs can't inherit from classes (as it says in the docs, "A
struct cannot inherit from another struct or class") then you can't go
around saying that structs "inherit" from ValueType without somehow
contradicting yourself.

So it seems that all value-types are structures.
Nope.

BTW, Reflector is a nice tool to have (I use it myself) but how it
displays classes or structs in its GUI might not be such a good indication
of how they are actually being managed by the CLR. I'd prefer to stick
with the docs on this one.

I think using the 'IL' setting is much more illustrative solution!

Chris.

 

[Christopher Ireland]

Hi Chris,


Probably because you can derive from them, which is uncommon for structs

Maybe you mean that they can be derived from, in the sense of being able to
create an enum which derives from (inherits) a byte, short etc. Rather like
a class ;-)

Chris.

 

[Dustin Campbell]

Thanks for the input, but I don't think this is simply a debate on

semantics. But just to address that concern, I do think that all
value-types can be considered structs. The term "structure" was not
coined in C#.

"Data types are separated into value types and reference types. Value
types are either stack-allocated or allocated inline in a structure"

"ValueType Class"
[link in related post]
System.Enum is also documented as a "structure" (see link in related
post).

System.Enum is actually a bit different from the types that derive from it.
System.Enum is certainly a structure. And, in accordance with the features
of structures, it declares static methods and implements interfaces. However,
types that derive from System.Enum cannot declare methods or implement interfaces.
So, are enums still considered structures? They are value types, yes but
they seem to have a feature set that separates them from structures.

Best Regards,
Dustin Campbell
Developer Express Inc.

 

[Dustin Campbell]

Maybe you mean that they can be derived from, in the sense of being

able to create an enum which derives from (inherits) a byte, short
etc. Rather like a class ;-)

That's just the underlying type though -- not true derivation.

<rant>
And speaking of this feature of enums, why in the world do I have to explicitly
type-cast an enum to its base type. This seems a bit like overkill:

public enum Fruit: byte { Banana, Apple, Orange }
private byte GetFruitIndex(Fruit fruit) {
return (byte)fruit;
}

If I declared the type specifically, it would be useful to be able to get
rid of the type-cast and clean up the code a bit.
</rant>

Best Regards,
Dustin Campbell
Developer Express Inc.

 

[Dave Sexton]

Hi Chris,

Nope.

Well, I'm going to have to continue to disagree with you on this point.

I think I've supplied ample documentation to prove otherwise. Even outside of
a C# context MSDN refers to value-types as structures. Consider the documents
that describe each of the primitive types, including System.Enum. The docs
all refer to each of them as "structure".

If you can produce evidence of a FCL ValueType that isn't referred to as a
structure in any MSDN documentation, then I might believe you.

I'll admit that calling all value-types "structs", not "structures", might be
misleading. But I do feel that they are semantically equivalent even though
"struct" really has special meaning to the C# compiler. Their equivalency is
in how they both refer to System.ValueType as the base class for an object.

 

[Dustin Campbell]

I think I've supplied ample documentation to prove otherwise. Even

outside of a C# context MSDN refers to value-types as structures.
Consider the documents that describe each of the primitive types,
including System.Enum. The docs all refer to each of them as
"structure".

If you can produce evidence of a FCL ValueType that isn't referred to
as a structure in any MSDN documentation, then I might believe you.

System.Enum is referred to as a "structure" in the documentation but any
type that derives is referred to as an "enumeration".

http://msdn2.microsoft.com/en-us/library/system.stringcomparison.aspx

Best Regards,
Dustin Campbell
Developer Express Inc

 

[Dave Sexton]

Hi Dustin,

Thanks for the input, but I don't think this is simply a debate on
semantics. But just to address that concern, I do think that all
value-types can be considered structs. The term "structure" was not
coined in C#.

"Data types are separated into value types and reference types. Value
types are either stack-allocated or allocated inline in a structure"

"ValueType Class"
[link in related post]
System.Enum is also documented as a "structure" (see link in related
post).

System.Enum is actually a bit different from the types that derive from it.
System.Enum is certainly a structure. And, in accordance with the features
of structures, it declares static methods and implements interfaces.
However, types that derive from System.Enum cannot declare methods or
implement interfaces. So, are enums still considered structures? They are
value types, yes but they seem to have a feature set that separates them
from structures.

So the question then is whether a structure is something that must be able to
implement interfaces and declare methods, or just something that derives from
System.ValueType.

Interesting question. Enums are special, however, because they are base
classes and structures, which is uncommon. Also, the C# compiler seems to
enforce certain rules about them.

Since I've been maintaining that the term structure refers to objects deriving
from System.ValueType, and because objects that derive from System.Enum
indirectly inherit from System.ValueType, I'm going to consider them to be
structures as well. I do believe that all value-types may be considered
structures because they can all be allocated on the stack, where as
reference-types can't.

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.

 

[Dave Sexton]

Hi Chris,

Maybe you mean that they can be derived from, in the sense of being able to
create an enum which derives from (inherits) a byte, short etc. Rather like
a class ;-)

No, I mean "derive from System.Enum". Reflector will show you what I mean.
Just look for an enum type and view the "Base Class" folder.

 

[Dave Sexton]

Hi Dustin,

And speaking of this feature of enums, why in the world do I have to
explicitly type-cast an enum to its base type. This seems a bit like
overkill:

public enum Fruit: byte { Banana, Apple, Orange }
private byte GetFruitIndex(Fruit fruit) {
return (byte)fruit;
}

If I declared the type specifically, it would be useful to be able to get
rid of the type-cast and clean up the code a bit.

Yes, but some people (I'm still not sure if I'm one of them) believe that the
lack of type-safety in Enums is problematic, and to allow implicit coercion to
the underlying type would further break whatever type-safety exists now.

I assume that the authors figured that:

1. Enums represent an enumeration of values and an instance represents a
single selection. Implicit coercion from the underlying type is like
"selecting" a value because the enum actually does represent the value to
which it is assigned.
2. Implicit coercion to the underlying type is like saying that the enum
instance IS the underlying type, which is misleading.

Just a guess

 

[Dustin Campbell]

Just a guess

I'm aware of the reasoning but I'm not convinced that this isn't a case of
overkill.

Best Regards,
Dustin Campbell
Developer Express Inc.

 

[Ben Voigt]

Since I've been maintaining that the term structure refers to objects

deriving from System.ValueType, and because objects that derive from
System.Enum indirectly inherit from System.ValueType, I'm going to
consider them to be structures as well. I do believe that all value-types
may be considered structures because they can all be allocated on the
stack, where as reference-types can't.

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

But that's somewhat redundant.

I don't see how this could get any clearer, than "structs" is a strict
subset of "value types". The MSDN article "Value Types (C#)" says:
The value types consist of two main categories:

a.. Structs

b.. Enumerations

Structs fall into these categories:

a.. Numeric types

a.. Integral types

b.. Floating-point types

c.. decimal

b.. bool

c.. User defined structs.

 

[Dave Sexton]

Hi Dustin,

System.Enum is referred to as a "structure" in the documentation but any
type that derives is referred to as an "enumeration".

That may be true, but in the same way that you would refer to any type that
derives from System.Exception as an "exception", but exceptions are still
objects, just like Enum-derived types are still ValueTypes, and therefore
structures. They can still be allocated on the stack.

 

[Christopher Ireland]

Hi Dave,

If you can produce evidence of a FCL ValueType that isn't referred to as a
structure in any MSDN documentation, then I might believe you.

I'll admit that calling all value-types "structs", not "structures", might
be misleading. But I do feel that they are semantically equivalent even
though "struct" really has special meaning to the C# compiler. Their
equivalency is in how they both refer to System.ValueType as the base
class for an object.

I'm quite happy with the IL definition of value types being classes which
extend System.ValueType. The docs define 'structure' as a 'user defined
value type' seeming to stear away from the issue of whether all value types
are 'built in' as structures.

Chris.

 

[Christopher Ireland]

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

If we replace 'value-types' in the above with 'System.ValueType', wouldn't
that be even better?

Chris.

 

[Dustin Campbell]

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.

 

[Dave Sexton]

Hi Ben,

Better: "I do believe that all value-types may be considered value-types
because they can all be allocated on the stack, where as reference-types
can't."

But that's somewhat redundant.

Well, no. I was implying that the term "structure" refers to an object that
may be allocated on the stack, and that value-types are therefore structures.

I don't see how this could get any clearer, than "structs" is a strict
subset of "value types".

But "structure" isn't. System.Enum documentation on MSDN refers to it as a
"structure".

Again, my use of the term "struct" is out of habit - I meant "structure"
whenever it was used outside of the realm of C#, which was probably most, if
not all of the time here. Sorry for any confusion.

The fact that C# refers to an enumeration as an enum, not "struct" (the
keyword) is irrelevant to this discussion. Remember, the original statement
was, "Not all value types are structures". It wasn't, "Not all value types
are structs".

 

[Dave Sexton]

Hi Chris,

If we replace 'value-types' in the above with 'System.ValueType', wouldn't
that be even better?

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

 

[Dave Sexton]

Hi Chris,

The docs define 'structure' as a 'user defined value type' seeming to stear
away from the issue of whether all value types are 'built in' as structures.

I'd like to see that documentation (not saying I don't believe you, but it
will help to prove your point).