# 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 lifeltime (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.