That's cute. Since System.Enum implements IComparable/IFormattable/IConvertible, it should have no trouble with the implicit conversions (section 13.1.4, ECMA-334).
As for the sbyte[]/byte[] conversion issue you cite, C# doesn't provide for array covariance on arrays of value types (section 19.5, ECMA-334). IMO the C# compiler is working per spec in this case. --Peter http://www.razorsoft.net/weblog http://staff.develop.com/peterd > -----Original Message----- > From: Discussion of the Rotor Shared Source CLI > implementation [mailto:[EMAIL PROTECTED]] On > Behalf Of Jeroen Frijters > Sent: Monday, August 19, 2002 12:50 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > Someone from Ximiam (the company leading the Mono effort) > joked (or may > be not!) that ILASM should be rewritten using Reflection (.Emit). If > that were possible that would be great. The current reflection API has > many CLS and C#-isms. Not being able to interchange sbyte[] and byte[] > is just one example. > > BTW, I found another bug in the C# compiler: > enum MyEnum {} > > class enumtest > { > public static void Main() > { > // following line doesn't compile > System.IComparable c = new MyEnum(); > } > } > > Regards, > Jeroen > > > -----Original Message----- > > From: Discussion of the Rotor Shared Source CLI > > implementation [mailto:[EMAIL PROTECTED]] On > > Behalf Of Christopher Brown (NDP) > > Sent: Monday, August 19, 2002 20:31 > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > What 'equivalence' would you expect from reflection? There may be > > instances where reflection policy is too stringent and we > > should take a > > look at them. > > > > Thanks, > > Chris > > > > > > -----Original Message----- > > From: Jeroen Frijters [mailto:[EMAIL PROTECTED]] > > Sent: Sunday, August 18, 2002 11:40 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > > Thanks, that's what I was looking for. I like this behaviour, but it > > does trigger a second question. Why doesn't Reflection > allow the same > > "type equivalence"? > > > > Regards, > > Jeroen > > > > > -----Original Message----- > > > From: Discussion of the Rotor Shared Source CLI > > > implementation [mailto:[EMAIL PROTECTED]] On > > > Behalf Of David Stutz > > > Sent: Monday, August 19, 2002 04:11 > > > To: [EMAIL PROTECTED] > > > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > > > > Section 1.8.1.2 of Partition 3 talks about the "verification type > > > system." As Peter points out, for verification, the number of > > > types can > > > be drastically reduced. Take a look at this section of the > > spec for a > > > fairly rigorous explanation. > > > > > > -----Original Message----- > > > From: Peter Drayton [mailto:[EMAIL PROTECTED]] > > > Sent: Sunday, August 18, 2002 11:32 AM > > > To: [EMAIL PROTECTED] > > > Subject: Re: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > > > > I think this is by design - there's really little difference > > > between the > > > signed and unsigned versions of the short data types, > except how the > > > bits are interpreted. Assigning a value >127 to an int8 simply > > > overflows. See example [1] below. Arrays of type "unsigned > > int8[]" are > > > assignment-compatible with arrays of type "int8[]" (see > example [2] > > > below), which supports this theory. > > > > > > On a quick troll of the ECMA specs I couldn't find the > > exact spot that > > > asserts this, though there are numerous references to > unsigned being > > > merely an alternate form of signed, and interpreted based > > on modifers > > > (unsigned) and special opcodes (e.g. *.ovf). > > > > > > --Peter > > > http://www.razorsoft.net/weblog > > > http://staff.develop.com/peterd > > > > > > [1] > > > assembly extern mscorlib {} > > > .assembly overflow {} > > > .method static void main() { > > > .entrypoint > > > .locals init (unsigned int8 b, int8 sb) > > > ldc.i4 128 > > > stloc b > > > ldloc b > > > stloc sb > > > ldloc sb > > > box [mscorlib]System.SByte > > > call void [mscorlib]System.Console::WriteLine(object) > > > ldloc b > > > box [mscorlib]System.Byte > > > call void [mscorlib]System.Console::WriteLine(object) > > > ret > > > } > > > > > > [2] > > > .assembly extern mscorlib {} > > > .assembly overflow {} > > > .method static void main() { > > > .entrypoint > > > .locals init (unsigned int8[] rgb, int8[] rgsb) > > > ldc.i4 1 > > > newarr unsigned int8 > > > dup > > > stloc rgsb > > > stloc rgb > > > ret > > > } > > > > > > > -----Original Message----- > > > > From: Discussion of the Rotor Shared Source CLI implementation > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of > > > Jeroen Frijters > > > > Sent: Saturday, August 17, 2002 11:43 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: [DOTNET-ROTOR] sbyte[] == byte[] > > > > > > > > > > > > When I call a method expecting a byte[] with an sbyte[], > > > the verifier > > > > doesn't mind. Is this by design or is it a bug? > > > > > > > > .assembly extern mscorlib {} > > > > .assembly test {} > > > > .module test.exe > > > > .imagebase 0x00400000 > > > > .subsystem 0x00000003 > > > > .file alignment 512 > > > > .corflags 0x00000001 > > > > > > > > .class private auto ansi beforefieldinit Test > > > > extends [mscorlib]System.Object > > > > { > > > > .method public hidebysig static void Main() cil managed > > > > { > > > > .entrypoint > > > > .maxstack 1 > > > > ldc.i4.1 > > > > newarr [mscorlib]System.SByte > > > > call void Test::Func(unsigned int8[]) > > > > ret > > > > } > > > > > > > > .method public hidebysig static void Func(unsigned > > int8[] b) cil > > > > managed > > > > { > > > > .maxstack 0 > > > > ret > > > > } > > > > > > > > .method public hidebysig specialname rtspecialname > > > > instance void .ctor() cil managed > > > > { > > > > .maxstack 1 > > > > ldarg.0 > > > > call instance void [mscorlib]System.Object::.ctor() > > > > ret > > > > } > > > > } > > > > > > > > Regards, > > > > Jeroen > > > > > > > > > >
