- GetAsyncEnumerator signature
- Ambiguities in nullable array type syntax
- Recursive Patterns Open Language Issues #2095
Discussed over email as well.
Proposal: bind e.GetAsyncEnumerator()
and use the result, including methods
with optional parameters or params
and extension methods.
We like the simple bind accepting optional parameters and params
, but
extension methods are a problem. We have a number of different features that
have backwards compatibility constraints preventing them from preferring extension
methods over interface implementation. In addition, the design of extension methods
is always as a last resort and we prefer code directly from the type (including
interface implementation).
Conclusion
Bind a lookup, but without extension methods. After looking for the interface,
consider extension methods. Follow-up issue to deal with the difference with
simple foreach
, which always looks for a zero-parameter method and doesn't
consider extension methods.
Q: What about [Caller...] attributes?
A: Let's do what we did for LINQ, which has to do roughly the same thing.
Do we respect the obsolete attribute in lookups in foreach, async foreach, and pattern dispose?
Conclusion
Yes.
Example:
if (o is string[][]?(var e0, var e1, var e2) s)
This is now ambiguous because the token after the ?
is not helpful in
resolving the ambiguity.
- Keep the order, but address using lookahead
- ? is a type constructor (reverse the order of brackets and question marks)
- reverse the order of ?'s only
- Introduce Array<T>
Array<int[]?>
new Array<int[]?>(3)
new Array<int[]?> { new[] {1}, null, new [] {2, 3 }}
- Don't allow nullability in jagged arrays
Conclusion
Let's try (2) and see how it works.
Yes, we think so.
Yes. The extra developer work required is worth it.
e switch {
1 => true,
2 => false,
}
Yes, permit optional commas anywhere there are curly braces, including switch expressions, property patterns, etc.
Scenarios that result in unnecessary warnings:
- Initialization helpers called from other constructors
- Factory methods that call constructors
- Object initializers
- Chained constructors
- Set-up/tear-down methods in test frameworks
- Reflection
Options:
- Do nothing, keep the current behavior
- Don't track initialization.
- No warnings for private constructors
- No warnings for constructors that call methods that might modify
this
- Track initialization debt with the class only, reporting warnings at public entry points.
- Track initialization debt across classes (and assemblies), reporting warnings where the object is constructed
Conclusion
Let's keep option 0 for now. We're worried about silently hiding legitimate warnings or that options 4 and 5 are too complicated or expensive to implement.