79 lines
No EOL
2.8 KiB
Markdown
79 lines
No EOL
2.8 KiB
Markdown
# C# LDM for May 6, 2020
|
|
|
|
## Agenda
|
|
|
|
1. `if (e is not int i)`
|
|
2. Target-typed conditional
|
|
3. Extension GetEnumerator
|
|
4. `args` in top-level programs
|
|
|
|
## Discussion
|
|
|
|
### `if (e is not int i)`
|
|
|
|
https://github.com/dotnet/csharplang/issues/3369
|
|
|
|
There are broader features that we'd to consider here as well, for instance allowing
|
|
some declarations below `or` patterns. However, this should be compatible with broader
|
|
changes and is easy to implement right now.
|
|
|
|
#### Conclusion
|
|
|
|
Accepted for C# 9. Further elaborations will be considered, assuming the schedule could
|
|
accept it.
|
|
|
|
### Target-typed conditional
|
|
|
|
We still unfortunately have a breaking change here with
|
|
|
|
```C#
|
|
M(b ? 1 : 2, 1); // calls M(long, long) without this feature; ambiguous without this feature
|
|
|
|
M(short, short);
|
|
M(long, long);
|
|
```
|
|
|
|
As always, breaking changes are very worrying, unless we are confident that almost no real-world
|
|
code would be broken. If the breaking change results in an ambiguity instead of silent different
|
|
codegen, that is substantially better, as people would at least know that the compiler changed
|
|
behavior. At the moment, we only think that this change could result in new ambiguities, not
|
|
different behavior.
|
|
|
|
#### Conclusion
|
|
|
|
We'll do some more investigation, try to find code that would be broken, and see if we can accept
|
|
the change.
|
|
|
|
### Extension GetEnumerator
|
|
|
|
https://github.com/dotnet/roslyn/issues/43147
|
|
|
|
Conclusions:
|
|
|
|
No objections to the proposals as written.
|
|
|
|
### `args` in Top-Level programs
|
|
|
|
If the top-level statements are logically inside a `Main` method, it would be very useful to have
|
|
access to the command line arguments for the program. You can access these via
|
|
`Environment.GetCommandLineArgs()`, but it's unfortunate that this is both different from the
|
|
APIs in Main, and `Environment.GetCommandLineArgs()` includes the program name, and `args` in
|
|
Main does not.
|
|
|
|
If we want to do something, we could have a magic variable named `args` (similar to `value` in
|
|
setters) or a property in the framework called `Args` (e.g. `Environment.Args`).
|
|
|
|
In favor of the property, fewer language-level changes means fewer things that people have to
|
|
learn.
|
|
|
|
In favor of the `args` magic variable, it's simpler to use than a property (since the property
|
|
would either have to qualified with a type name, or a `using static` would have to be added) and
|
|
a language feature for the inputs (command line args) mirrors the language feature for the output
|
|
(returning an `int` that turns into the process exit code).
|
|
|
|
#### Conclusion
|
|
|
|
We'll go with the `args` magic variable. We still need to decide on the scope: either equivalent
|
|
to top-level locals, which are visible in all files but inaccessible, or only in scope in
|
|
top-level statements. If we make it visible in all files we would only add the variable if there
|
|
is at least one top-level statement in the program. |