# C# Language Design Meeting for July 27th, 2022

## Agenda

1. [`scoped` for local declarations](#scoped-for-local-declarations)

## Quote of the Day

- *nervous chuckling* "That's actually an interesting question!" "I know, it's just when you say scary things."

## Discussion

### `scoped` for local declarations

https://github.com/dotnet/roslyn/issues/62039  
https://github.com/dotnet/csharplang/issues/1147

Today, we looked at allowing `scoped` as a local modifier in all local declaration context, such as `using`s, `foreach` iterator variables, and such. We like the idea in principle: users don't
think of the various different grammatical ways of creating a local variable differently, they think of them all as locals. There were a couple more in-depth points of discussion about the
implementation:

* Is `scoped` or not something that `var` should be able to infer? This matters for deconstruction, as in `var (x, y) = MethodCall();`. After some consideration, we don't think scopedness is
something we can or should infer. It might also vary between each of the deconstruction variables. Given this, we think that `scoped` needs to explicitly declared, not inferred in any local case.
* The specification for `scoped` doesn't particularly line up with how we consider modifiers. We'd like to think of this as a new kind of modifier, a modifier that must go directly on a type, rather
than a modifier that can go anywhere in the modifiers list of a method. Unlike method modifiers, `scoped` is specifically a modifier on either the return value or a parameter value, and should be
applied in those locations. `scoped unsafe Span<int> M() => ...;`, for example, isn't legal. The `scoped` affects the return, while the `unsafe` generally affects the method body. We therefore think
that the specification (and Roslyn implementation) should match this intuition.

#### Conclusion

We approve the general concept in this issue, but the grammar specification needs to be updated.
