# 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*` 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 (...)`.