Skip to content

Latest commit

 

History

History
79 lines (53 loc) · 2.8 KB

LDM-2020-05-06.md

File metadata and controls

79 lines (53 loc) · 2.8 KB
Raw

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)

#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

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

dotnet/roslyn#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.