Added: LDM notes for June 17, 2020

[SingleAccretion]

C# Language Design Notes for June 17, 2020

Records:
1. Null-suppression & null-conditional operator
2. parameter! syntax
3. T??

[orthoxerox]

The biggest argument for !! is that it can be made available in method bodies as well: LegacyLibrary.GetSomething()!!.

[iam3yal]

I really like ?? throw which was suggested by Cyrus.

[SingleAccretion]

I really like ?? throw which was suggested by Cyrus.

I too would prefer that syntax, as it makes clear there will be an exception at runtime and uses familiar constructs. But I do fear this might be a case of "making the feature stand out" bias.

public void ProcessPayments(IReadOnlyList<Payment> payments ?? throw, Person sender ?? throw, Person receiver ?? throw) { ... }
//vs
public void ProcessPayments(IReadOnlyList<Payment> payments!, Person sender!, Person receiver!) { ... }

One aspect to consider here is that with NRTs (ideally) these checks should only be performed at API boundaries, thus making them more visible and differentiating "caller is trusted" and "caller is not trusted" might actually be a good thing. The verbosity in this case should also not be that big of a problem since it is still much shorter then the custom check and public methods are not as numerous as internal/private ones.

[iam3yal]

@SingleAccretion I dislike scrolling horizontally so I'd probably go with the following style anyway.

public void ProcessPayments(
    IReadOnlyList<Payment> payments!, 
    Person sender!, 
    Person receiver!) { ... }

So the following wouldn't be much of an issue:

public void ProcessPayments(
    IReadOnlyList<Payment> payments ?? throw, 
    Person sender ?? throw, 
    Person receiver ?? throw) { ... }

But some people dislike this style so I can see why they might not be in favour of this.

[HaloFour]

@orthoxerox

I like the idea of having a nullable "unwrap" syntax that can be used in expressions that would not only silence the compiler but also throw if the expression is null. My only concern is that !! is so close to ! that it would be easy to typo or accidentally miss while reading.

[pinkfloydx33]

For ?? I don't really like default (i) . While I would understand what it meant (after thinking about it for a second), I don't think it's meaning would be obvious enough--especially to someone new to the language. In that regard I'd prefer the or or | variants (g/h) except that it then implies you could combine other constraints that way. While I'm usually for succinctness, I'm glad that T?? isn't being considered as the single extra token could be difficult to parse visually and easy to miskey (it's one reason I don't like ! for the null checks).

I know that you typically try to reuse keywords where possible but eventually it's going to seem like forcing too much into a single keyword/token. I think that the best and perhaps most obvious choice is unconstrained (c) as it tells you what it means and doesn't leave too much to guesswork (there's also precedent for new keywords with the unmanaged and notnull constraints).

The one option I would be absolutely against is the attribute version (a). I feel too much is beginning to require attributes, especially with NRTs. It's either a language feature or its not--and while the attributes are used by the compiler they look and feel like they aren't actually part of the language.

Another option could maybe be where T: class, struct though I suppose that reads as an and rather than an or which is why I suspect it wasn't considered.

[TheUnlocked]

I don't like T: default at all. To me, it reads as "T is constrained to the value default," which is definitely not the intent. T: unconstrained describes what it's supposed to mean (which is very important!), but to me it looks a bit too "spooky" and unfamiliar from an aesthetic perspective. I prefer the class or struct/class|struct constraints, as if you know what T: class and T: struct mean, you know what the syntax for the unconstrained type constraint means as well.