103 lines
2.3 KiB
Markdown
103 lines
2.3 KiB
Markdown
# C# Language Design Notes for Jan 11, 2017
|
|
|
|
*Raw notes - need cleaning up*
|
|
|
|
## Agenda
|
|
|
|
- Language aspects of [compiler intrinsics](https://github.com/dotnet/roslyn/issues/11475)
|
|
|
|
Intrinsics
|
|
|
|
Two compiler behaviors:
|
|
1. Recognize declarations as intrinsics, and implement them
|
|
2. 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
|
|
|
|
|
|
|
|
|
|
``` c#
|
|
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).
|
|
|
|
``` c#
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|