I was considering introducing the OneOf library into our codebase, but if this is < a year or so away it might not be worth the effort.
Tearing can cause memory safety issue. Variant A can have an integer field and variant B can have a reference field in the same offset. Tearing can cause it to treat an integer as reference.
It is possible to overlap fields in this way, though offsets occupied by an object reference shall not overlap with offsets occupied by a built-in value type or a part of another object reference.
Per .NET 8.0:
using System.Runtime.InteropServices;
var s = new S { Bar = "Baz" };
[StructLayout(LayoutKind.Explicit)]
public struct S {
[FieldOffset(0)] public UInt64 Foo;
[FieldOffset(0)] public Object Bar;
}
compiles, but throwsSystem.TypeLoadException: Could not load type 'S' from assembly 'foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because it contains an object field at offset 0 that is incorrectly aligned or overlapped by a non-object field.
Interestingly, this code elicits a warning
ILC: Method '[foo]Program.<Main>$(string[])' will always throw because: Failed to load type 'S' from assembly 'foo, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' because of field offset '0'
from the AOT compiler, but none from the C# compiler.
The C# compiler has very little knowledge of `[FieldOffset]`. It's expected that developers understand the runtime implications of this.
Besides that, the feature I want most in C# is enum exhaustion checking. So I can write:
enum Color { red, green, blue };
public static string SuperheroFromColor(Color c)
{
if (c == Color.red)
{
return "Superman";
}
else if (c == Color.green)
{
return "Green Lantern";
}
else if (c == Color.blue)
{
return "Spiderman";
}
}
and not get a compiler error (that not all code paths return a value). But if I added "yellow" as an enum option, then I would get a compiler error. I realize that Color can be cast from an out-of-range int, so it's a little complicated. I'm willing to put something extra after the last else: unreachable return null;
or use a special switch statement. I just want something so the compiler checks that I have accounted for all normal enum values.Is anyone talking about such a feature, or where would I request it? Can I write it myself as a Roslyn extension?
Generally, I like it, but it can be a bit sluggish at times. The only plugin I have running is JSLint, so I suspect it's VSVim causing the problems (though it only generally bogs down when I leave VS2010 for a bit). The keybindings work as one would expect. As I mentioned in a different thread, I wish it could break out of the tabbed window convention of VS and use buffers.
ViEmu did feel a bit faster (and was less prone to crashing).
https://github.com/downloads/jaredpar/VsVim/VsVim-1.2-Beta2....
As for crashes I'd love to hear about any you found. Feel free to send me email (hacker news alias at microsoft.com) or post an issue on github.
It's got some serious bugs that make my heart stop.
The biggest one is Undo. Looks like the plugin keeps it's own list of modifications that were performed. So when sometimes I press "u" to undo the latest change - Visual Studio gets suspended for a minute or two, and all my changes that I did since I opened Visual Studio (could be a day or a week) are pretty much gone. The work around is to close the file without saving.
Bug Details: https://github.com/jaredpar/VsVim/issues/672