2.3 KiB
C# Language Design Notes for Jan 11, 2017
Raw notes - need cleaning up
Agenda
- Language aspects of compiler intrinsics
Intrinsics
Two compiler behaviors:
- Recognize declarations as intrinsics, and implement them
- Enforce whichever special rules apply on call
Could grow the list over time.
Scenario: avoid il rewrite or inefficient impls
Lets you do cross-platform libraries.
This feels cheap, and limits the implact to just the compiler.
Can't be abstracted out into generic methods - at least without combinatorial explosion
Some might be obsoleted over time as language features ("static delegates"?) come along.
Could allow optionally specifying the intrinsic name in the attribute, so you could call the method something else if you like
Open question: local functions.
Wouldn't emit to metadata.
How supported should this be, as a language feature? Should semantic analysis understand this, and give you good live feedback? Doesn't need a lot of tooling support out of the gate; it's a feature for a very small set of
switch(...)
{
case string s when .... x1:
case int i when .... x2 & capture x1:
case 1 when ... capture x1;
break
case string s when .... x3:
case int i when .... x4:
case 1 when .... & capture something
break;
}
The code needed to be surprised by the lifetime of expression variables in case headers being the whole switch block is quite convoluted (just like this sentence).
case 1 => WriteLine(...);
case 2
{
}
case string s when (...)
{
...
}
- Broaden scope and lifetime of expr variables to whole switch block
- Broaden lifetime of expr variables, but not the scope
- Limit scope of variables in bodies of cases that are "new"
When there are expression variables in the case header, in the case body forbid:
- ref locals
- to expr variables
- local functions
- that capture case-section expr variables
- labels
- that are jumped to from other case sections
Drop the subbullets for now, and maybe we can relax later
Out of all these approaches, we still think expanding the lifetime (but not the scope) has the lowest risk. Fallout work is likely in the debugger, which will have a suboptimal experience in these scenarios. This work is probably puntable.