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

C# Language Design Notes for Oct 15, 2018

Agenda

1. Function pointers
2. Readonly struct members
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 (...).