Added: LDM notes for Oct. 31, Nov. 5, and Nov. 14

[agocke]

Oct 31, 2018

C# Language Design Notes for Oct 31, 2018

• Design review

Nov 5, 2018

C# Language Design Notes for Nov 5, 2018

1. Where can #nullable go?
2. Open issues with pattern matching

Nov 14, 2018

C# Language Design Notes for Nov 14, 2018

1. Base call syntax for default interface implementations
2. Switch exhaustiveness and null

[CyrusNajmabadi]

Flow analysis constrains refactoring because something may be tested null by flow analysis, but if you pass to a new method, the flow analysis is lost. For example:

This makes sense to me. Someone else may be calling the method and may not have validated that the props are non-null.

Now, it's an open question if IDE shuld then add the null checks in for you.

[CyrusNajmabadi]

Treating the delegate conversion as executing the method is unsafe, but not doing so is conservative and will warn on valid checking. TypeScript has also hit this and there's no easy answer.

THis is probably the #1 case i need to use the ! in TS for. It is indeed annoying.

[CyrusNajmabadi]

If the argument being switched on can be trivially boxed into object

What argument coudl not be trivially boxed into 'object'?

[orthoxerox]

! on parameters

Does SomeType! param mean if (param is null) throw new ArgumentNullException(nameof(param)); is injected into the body?

I'd rather autoinject it everywhere via a compiler switch than scream! in! every! public! method!,

[dsaf]

@CyrusNajmabadi

If the argument being switched on can be trivially boxed into object
What argument coudl not be trivially boxed into 'object'?

Why is "argument" term even used here? Whatever you are switching on is an "expression" isn't it?

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/switch

In C# 6, the match expression must be an expression that returns a value of the following types:

a char.
a string.
a bool.
an integral value, such as an int or a long.
an enum value.

Starting with C# 7.0, the match expression can be any non-null expression.

[alrz]

warning about not handling all inputs except null.

If NRT affects switch exhaustiveness warnings (dotnet/roslyn#30597), why we couldn't use switch (obj!) to not get a warning on null?

[DavidArno]

Currently (and I assume this will be the case when v8 ships), pattern matching on enums will always complain that the switch expression is not exhaustive. For example, if I do the following:

public enum FooBar { Foo, Bar }
...
var x = FooBar.Foo;
var y = x switch {
    FooBar.Foo => 1,
    FooBar.Bar => 2
};

it gives me the warning, warning CS8509: The switch expression does not handle all possible inputs (it is not exhaustive).

Since the new exception, MatchFailureException, is being introduced, I have two choices here:

1. Ignore the warning and get a MatchFailureException if the enum value isn't one of the specified ones at runtime, or
2. Add a default case.

But since that exception is going to be introduced, it makes sense for me to use it in my default case:

public enum FooBar { Foo, Bar }
...
var x = FooBar.Foo;
var y = x switch {
    FooBar.Foo => 1,
    FooBar.Bar => 2,
    var e => throw new MatchFailureException(e.ToString()) 
};

So now, I'm explicitly duplicating what the compiler would implicitly do for me just to suppress a warning.

I don't like disabling warnings and would be loathe to do so here, as that exhaustiveness check would make sense elsewhere. But I don't want to have to write duplicate code just to work around the warning either.

So is there any way in which that warning could be suppressed for enums to avoid the need to duplicate things?

Tagging @gafter here in case he has a view on this.

[alrz]

So is there any way in which that warning could be suppressed for enums to avoid the need to duplicate things

Integral enums would be only one instance, I think non-exhaustive switch expressions would not be that uncommon. perhaps there should be simple syntax like switch! to suppress that warning.

[HaloFour]

I'm with @DavidArno on that point. Yes, technically the switch is non-exhaustive, but an enum value that doesn't match one of its elements should be considered exceptional, IMO. That said, I could see still warning if none of the enum elements equal 0 as that would be the default value:

[alrz]

enum value that doesn't match one of its elements should be considered exceptional

Perhaps in the absence of FlagsAttribute? I think a warning could also be useful on bitwise operations and the like on non-flag enums so that we get sensible warnings/lack of warnings on both sides. Same for zero, I'd expect a warning when an "invalid" value is produced if exhaustiveness depends on it to be correct.

[HaloFour]

@alrz

Perhaps in the absence of FlagsAttribute?

Ah, that's true. Enums can be wonky beasts. I'd still think that the most common use of enums would be non-flags with a 0 element, but I don't know if it's be worth baking that into the spec.

[DavidArno]

@HaloFour, I add to what you say by suggesting that if I only match on FooBar.Foo, I should still get a warning as I'm ignoring FooBar.Bar.

So taking your point about 0, @alrz's point about flags and the above into account, what I'm looking for is for no warning if the enum doesn't have FlagsAttribute and all the explicit values, plus 0 are covered by the switch.

[Unknown6656]

I don't like the base call syntax for default interface implementations.
Even if base(...) matches somehow the "feel" of typeof(...), sizeof(...) or nameof(...), I would rather want to see that with angled brackets or with double-colons: base<...> or base::...

This is specially important to me, as I am a huge supporter of functors. Obviously the currently proposed syntax would interfere with functor inheritance (Imagine a math-library with mathematical functions which have some kind of inheritance relationship).