1.8 KiB
C# Language Design Notes for Nov 6, 2017
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
Roslyn 20870
Protecting the client from unintended dependencies. But also protects from servicing. Today people going through reflection know they're being bad. Would this give enough sense that they are doing something special.
It would make consumers lazy about contacting the API owner about things they need exposed.
It would be an arms race - we would want the IgnoreIgnore... attribute to really protect things.
People will still have expectations about dependencies even if it was "their own fault" by using this attribute.
Conclusion
Too risky/fishy in too many ways.
Roslyn 17310
There is no good language level solution right now. This is better addressed with an analyzer, which can know specifically about SpinLock (for instance).
In time, when readonly struct declarations are added, as well as maybe the ability to declare individual struct members as readonly, then maybe we could start warn.
Conclusion
Not at the language level
Roslyn 20450
We have sympathy. It feels like a corner that's cut. But it's quite expensive to implement, and has semantic dark corners (List<>.First.Foo).
Conclusion
Not now.
Roslyn 20015
When default-expressions are constant (according to the language) this is not interesting expressiveness - there's a literal you can use.
When they are not it gets a bit more interesting - you might want to check that your custom struct is zero-initialized. But you can do that with equality. Even in recursive scenarios, you can just var-pattern it and check in when or &&.
Additionally there is some concern about the target type being clear enough for the default expression.
Conclusion
No.