1.9 KiB
C# Language Design Notes for Mar 7, 2017
Raw notes, yet to be cleaned up - read at your own peril
Default
We allow null == null, should we allow default == default?
as and is: work for null.
Question: When should I use default, when should I use null? Style wars?
Can't use null as the syntax for this, as it would allow null to convert to int, which would be breaking.
We could also disallow default, when the type is known to be a reference type.
Let's not restrict it in the language. It would be a matter of style, and the IDE might give you options about it. The default would probably be null when we can, default otherwise, and default(T) when we have to.
"Now case default: is allowed!" :-) warning?
Resolution on not-typed syntax that works for null: don't. No throw default, no default == default, etc.
default as long still disallowed, because the rhs can't be a non-nullable value type.
default as string allowed
x is default is not allowed when x is default(T) would have been allowed, where T is the type of x. That's because we check whether the rhs is a constant, before its conversion.
default is T should not be allowed. It would not mean the same as default(T) is T, but more like default(object) is T, which is always false.
"Now (T)default means the same as default(T) :-)"
Field target
We like this, the design is great, we are good with the drawbacks. If the break turns out to be significant (it won't), we can loosen the specific case.
private protected
Let's really assure ourselves that this works in the runtime!
What will F# do? They need to understand the metadata even if they can't "see" the members
Lots of tools might get confused. CCI?
It was in C++/CLI but that may not have exercised enough.
Needs to go into C# and VB.
Fair amount in the IDE - test intellisense works out, refactorings etc. Keyword recommendations, etc.