469,292 Members | 1,578 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,292 developers. It's quick & easy.

Type alias in C#

Maybe I'm stupid or maybe I am missing the obvious, but I can't find a way
to define a type alias in C# for primitive types (class and interfaces I can
inherit from, no problem). I.e I want to declare a type that is an alias
for, say, int. Conceptually, this is what I want to do:

public MyIntType = int; // won't compile

Anyone knows how to do this?

--
Regards, Peter
Nov 7 '06
59 10358
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

Nov 8 '06 #51
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.
Nov 8 '06 #52
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.
Nov 8 '06 #53
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.
Nov 8 '06 #54
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)"

--
Christopher Ireland

"Getting married for sex is like buying a 747 for the free peanuts."
Jeff Foxworthy
Nov 8 '06 #55
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.

--
Dave Sexton
Nov 8 '06 #56
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.
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.
Nov 9 '06 #57
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.

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.
>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 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/ar...classenum.aspx

--
Dave Sexton
Nov 9 '06 #58
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/ar...classenum.aspx
Hi Dave,

You might also consider my own article here: http://diditwith.net/PermaLink,guid,...05cef6aad.aspx.
:-)

Thanks for the lively debate.

Best Regards,
Dustin Campbell
Developer Express Inc.
Nov 10 '06 #59
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.

--
Dave Sexton

"Dustin Campbell" <du*****@no-spam-pleasedevexpress.comwrote in message
news:c1**************************@news.microsoft.c om...
>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/ar...classenum.aspx

Hi Dave,

You might also consider my own article here:
http://diditwith.net/PermaLink,guid,...05cef6aad.aspx.
:-)

Thanks for the lively debate.

Best Regards,
Dustin Campbell
Developer Express Inc.


Nov 10 '06 #60

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by David Ford | last post: by
26 posts views Thread by Adam Warner | last post: by
2 posts views Thread by Scott Ribe | last post: by
6 posts views Thread by Maxim | last post: by
669 posts views Thread by Xah Lee | last post: by
7 posts views Thread by chaz | last post: by
6 posts views Thread by dillogimp | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by harlem98 | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.