LDM Notes for September 4th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-04.md

Agenda

• Triage (no milestone)
  • Type inference using method group natural type
  • Collection Expressions Next (C#13 and beyond)
  • Dictionary expressions
  • Extending patterns to "as"
  • params in parameters
• Triage (working set)
  • Only Allow Lexical Keywords in the Language
  • Permit variable declarations under disjunctive patterns
  • CallerCharacterNumberAttribute
  • Task<T> nullability covariance
  • Nullable analysis of LINQ queries

[MitchRazga]

Really liked this meetings notes. Was a good insight into the LDTs focus areas.

How does the LDM approach topics that are not yet proposals but are more about improving/expanding existing features?
Without a proposal, feedback can get spread over multiple discussions/issue comments which may be difficult to find when it comes time to look at that area again.

For example, something like ref record struct has been mentioned in a few different areas and is even mentioned in the Type Unions Proposal but there is no centralized discussion area since it has no proposal.

Should community members be necroposting on already implemented proposals to keep this feedback centralized? eg. #39
With GitHub Discussions, my concern is that since multiple threads may discuss the same topic but with a different title/keywords or if they have to many comments (as mentioned in the readme ) they might be missed by the LDT.

Also, @333fred the link has broken after commit cd4d9a4

[333fred]

Thanks for the ping, I meant to go update this yesterday but forgot.

As to things that are not yet proposals, it really varies on the member. Your best bet is to comment on some existing discussion, or opening a new one; commenting on an existing, implemented feature is likely just going to get comments that this feature has been implemented, please go open a new discussion. Several members of the LDM (myself included) subscribe to this repo and see every comment made on every discussion; some of us may not chime in very often, but we are watching.

[CyrusNajmabadi]

but we are watching.

We're always watching wazowski.

[MgSam]

I'm confused about the feedback on #8210. The LDM feedback talks about how it would change is. Unless I'm missing something the proposal is entirely about expanding as, not changing is.

Also, I think many people preferred the when syntax, which I think is highly consistent with the existing usages of when in C#. Should that be broken out into a separate proposal?

[333fred]

The LDM feedback talks about how it would change is.

Correct. That's exactly what it would do: collapse the true/false branches of a proper pattern match into not null and null. This then needs to be tested again for null, rather than just using the original outcome of the is.

Also, I think many people preferred the when syntax, which I think is highly consistent with the existing usages of when in C#. Should that be broken out into a separate proposal?

No. Both suffer the exact same problem. It is not the use of the word as that we dislike: it's the collapsing of condition.

[chrisoverzero]

The proposal is for the keyword spelled “ay-ess,” as is @MgSam’s question. But the responses both there and here are about the keyword spelled “eye-ess.”

Maybe the LDT can see three steps ahead where I cannot, but I don’t understand how the one got to the other.

[333fred]

Sarcasm is not helpful. I'll say again, an as pattern is just is pattern x ? x : null, the result of which then immediately has to be checked for null. We do not like this.

[chrisoverzero]

That wasn’t sarcasm at all – I genuinely didn’t understand. Now I see the middle step, thank you.

I’ll say again […]

At the risk of upsetting you further, part of the reason I didn’t understand is that this was left out of the explanation. It’s a proposal about changing as, and the LDT’s response is about is. In your response, you confirmed that it was about a desire not to change is. I don’t think it’s unreasonable to wonder, since is wasn’t changing, whether some steps were skipped in the explanation because of the LDT’s expertise (alternatively, mis-reading), and it turns out that it seems like they were.

[333fred]

I'm certainly willing to hear feedback on how to make the notes clearer. However, I don't know how read a comment like The proposal is for the keyword spelled “ay-ess,” except as sarcasm, as it implies that I don't know how to spell.

[jnm2]

A use case came up where I would have written:

var match = regex.Match(input) as { Success: True }
    ?? throw new InvalidOperationException(...);

[jnm2]

I wouldn't see any value in requiring that they be paired, limiting composability. For instance, maybe you want to add on ?.Xyz before coalescing with null. The language lets you combine features in ways that lead to poor understandability in a myriad ways already. Limiting the language's power to try to prevent people from writing confusing code seems like a dubious tradeoff with little prospect of big-picture success toward such a tenet.

[jnm2]

I'm currently at: I'd use it, I'd like using it, but so far it feels infrequent enough that I wouldn't be strongly in favor of investing in it, particularly over other things. For instance, I'd rather have compound assignments in initializers and with, and null-conditional assignments.

[CyrusNajmabadi]

I'm currently at: I'd use it, I'd like using it, but so far it feels infrequent enough that I wouldn't be strongly in favor of investing in it,

I'm in a similar boat. And I personally think I'd use it so rarely that I think it's too cute and too niche to be worthwhile

[RikkiGibson]

In the world without as-patterns I think the following is the best way to write it

var match = regex.Match(input) is { Success: True } m ? m
    : throw new InvalidOperationException(...);

Or, in the specific case of wanting to assign to a local:

if (regex.Match(input) is not { Success: True } match)
    throw new InvalidOperationException(...);

[jnm2]

Seeing var match = at the start of the line has felt like an improvement to me, but it is such a special case. Not every guard can coalesce to ?? throw.