74 lines
2.7 KiB
Markdown
74 lines
2.7 KiB
Markdown
|
|
# 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 (...)`.
|