# 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.