On Jan 5, 2011, at 3:45 PM, Miguel de Icaza wrote: > I hate this behavior, and I believe it was introduced around c# 3
I'm not sure what you're saying. That this is csharp standard behavior? Can you point me to a reference or discussion of this? Further poking finds that 'Field' just needs to be in a referenced assembly. Field's assembly doesn't need to be compiled by VisStudio, it can be compiled by gmcs. The problem is that downstream of 'f = null', we have code that does 'f == null' and 'f != null', which does one thing under .NET and another under Mono. That's no fun. If that code is compiled by gmcs, we get a compile-time warning (CS0472) and can fix it. But many of the assemblies are intended to be compiled only by VisStudio. Some of the assemblies CAN ONLY be compiled by VisStudio because their projects rely on VisStudio plugins. So all we have is unexpected runtime behavior, which we have to search for at runtime. Is there some way to inspect the VisStudio-produced assemblies and find all instances of these "compare struct to null"? Another solution would be to teach VisStudio to not allow 'Field f = null' or 'f == null', then everyone working on .NET alone would have to write code that conforms to Mono's behavior. Is that possible? > On Wednesday, January 5, 2011, Eric Slosser <[email protected]> wrote: >> <csharp newbie> >> >> I have a C# struct that's defined as >> >> public struct Field : IComparable, IComparable<Field>, >> IEquatable<Field> >> { >> } >> >> When I do this: >> >> Field f = null; >> >> I'd expect error CS0037 (can't convert null to 'Field' because it is a value >> type. >> >> But when Field is defined in an assembly that was compiled by VisStudio, >> gmcs (v2.8.1.0) is happy to let me assign null to it. > _______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
