2 KiB
C# Language Design Notes for Mar 28, 2017
Raw notes, yet to be cleaned up - read at your own peril
Agenda
Design remaining 7.1 features
Default
expr is default
It would not be a place where null and default mean different things, because null wouldn't be allowed there (doesn't convert to the type of the lhs).
Brittle wrt the type of the expr. But we already have that with 0, for instance, which is int 0 always, except when the context is some other numeric or enum type.
We'll leave it allowed wherever null is allowed as a pattern, as well as wherever default is a constant when converted to the type of the lhs.
case default:
Should this be legal? It is probably a mistake. Make it a warning. Just that particular syntactic thing. You can put parens around it, or write default(T), etc.
permit match of expr of type T:base with derived
Today x as T is allowed if
- there is a reasonable relationship between the left and right type, or
- one of them is an open type
But for the is operator we don't have 2. That means that we can't always replace uses of as followed by null check with an is with a type pattern.
Also, the restrictions are supposed to rule out only obviously useless cases, whereas some of these are demonstrably useful.
Let's allow it, look again if there are unexpected problems.
Better common type
Best common type should combine a value type with null literal to get a nullable value type.
b1 ? 1 : b2 ? null : b3 ? 2 : default; // default is 0
b1 ? 1 : b2 ? default : b3 ? 2 : null; // default is null
b1 ? 1 : (b2 ? null : (b3 ? 2 : default)); // default is 0
b1 ? 1 : (b2 ? default : (b3 ? 2 : null)); // default is null
This is weird, but fine.
M(1, default, null); // int?
Next step is trying to spec it. It's a bit complicated.
M(myShort, myNullableInt, null); Should continue to infer int? , not short?