csharplang/meetings/2018/LDM-2018-10-15.md

# C# Language Design Notes for Oct 15, 2018

## Agenda

1. [Function pointers](https://github.com/dotnet/csharplang/blob/master/proposals/function-pointers.md)
2. [Readonly struct members](https://github.com/dotnet/csharplang/issues/1710)
3. Syntax for async streams

## Discussion

### Function pointers

We're leaning towards no names. The encoding and scoping of the naming seems
like it could be a problem. Not having names is not a new problem and it does
not seem worse than far more common things like tuples. We many consider a
richer augmentation of aliasing in general, which would help not only
function pointers, but all the places where you may want to alias an existing
type.

Syntax: we played around with multiple funcptr type syntaxes. We haven't
settled on a syntax yet, but we have been convinced by Jared that the
`Func<a,b>*` syntax is unworkable. If we later introduce a new structural
function pointer type and syntax, we could evolve the current syntax to
support the new syntax.

*Q: Do we want the '&' when converting a method group to a `funcptr`?*

One argument is that it's extra syntax at the place where the feature is
least unsafe (at the declaration), instead of the place where's it's most
unsafe (at the invocation). However, it is similar to syntax for other
pointer types in the language and "feels right" when you see it. Let's keep
it.

**Conclusion**

We like this approach a lot more than the previous attempt. The main item
left is to make sure the syntax is unambiguous.

### Readonly struct members

We discussed this feature back when we added "readonly" for struct
definitions and decided we might consider it later. It is now later.

Looking back on the language, we feel the silent copying of structs to avoid
mutation is a bit of a wart. One thing stopping us from providing a warning
is the lack of this feature, since sometimes you cannot mark a struct
readonly just to avoid the copy. This feature would fill out the space enough
that we could consider a warning wave or an analyzer to warn about silent
struct copies.

Examined a few syntaxes for this:

- An attribute ([ReadonlyMethod]?)
- `readonly` at the end
- `readonly` at the beginning
- Allow the explicit `this` parameter and let it be passed by `in`

**Conclusion**

We like the feature and think the syntax should be a `readonly` modifier at
the beginning of the method, along with the other modifiers.

### Syntax of `foreach await`/`using await`

`foreach await (...)` or `foreach async (...)` or `async foreach (...)`?

In the past we've followed the pattern that there's always an explicit
`await` in the code if we're awaiting. There's some debate on what sounds
best.

**Conclusion**

`await foreach (...)` and `await using (...)`.