Added: LDM Notes for December 16th, 2020

[333fred]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-12-16.md

Agenda

• List patterns
• Definite assignment changes

This is the last LDM for 2020: we'll be back again at the beginning of January.

[HaloFour]

I'm really curious as to how the team is imagining indexer patterns being implemented given that indexer properties often can throw if the index is out of range or doesn't exist. IMO it would be a real pit of failure if the pattern could throw due to a recursive indexer pattern that refers to an index that doesn't exist.

[YairHalberstadt]

I would want some way that indexer patterns on Dictionary mapped to TryGetValue instead of the indexer.

[HaloFour]

Given the compiler can't tell an IList<T> from an IDictionary<int, T> IMO it'd be wise to rely on binding to such a method for indexer patterns in general. Extension methods could be provided for existing collection types.

List<string> list = ...;
if (list is { [12]: "foo", [13]: var value }) {
    Console.WriteLine(value);
}

// compiles effectively to:
if (list != null && list.TryGetIndex(12, out var _) && list.TryGetIndex(13, out var value)) {
    Console.WriteLine(value);
}

[alrz]

For types that support range indexer pattern, I think we can emit the length check just like we do for list patterns.

For Dictionary, I'd much prefer #4131, but that's probably not a satisfying solution in which case we end up special casing TryGetValue.

[333fred]

how the team is imagining indexer patterns being implemented

We're not imagining specifics currently, we'd certainly need to be able to account for this scenario though. This is mainly a "well, we know we want to fill in more of that table, and this syntax is the natural fit and works well with the rest of the proposal."

[MgSam]

For the definite assignment changes- is there a scenario not involving out that these changes improve? If so, why has this become a priority now? Given that out doesn't work with async, and tuples or records are now a much easier way to do multiple return values, I rarely ever see or use out these days.

[jnm2]

I'd say the clock started ticking when C# 6 was released and ?.Foo(out var bar) became possible. Things move slowly, and this bugs me infrequently but regularly, so it doesn't seem surprising to me that this is finally gathering steam.

[CyrusNajmabadi]

If so, why has this become a priority now

Becuse it's painful and unpleasant and means code that should be idiomatic has to be written in a much more ungainly style.

[MgSam]

My point was it's not idiomatic anymore. In "real" code out was already rare and since widespread async adoption has become virtually extinct. The only place I ever see it used are those few instances in the BCL where legacy Try methods have an out parameter, areas which are all much nicer to user with GetValueOrDefault() or tuple-returning alternatives instead.

[HaloFour]

They're still idiomatic. Nullable value types were around when the TryParse family of methods were added to the BCL and the team at the time believed strongly that nullability and failure to parse were not to be conflated. Proposals to add overloads of those methods have also been declined by the team.

edit: link posted to nullable TryParse proposal, not tupled

[RikkiGibson]

I don't think it's accurate to consider the TryParse pattern to be legacy that has been replaced with something else, even if it may seem clunky--especially since we have the ability to describe nullable behavior of TryParse-style methods using NotNullWhen/MaybeNullWhen attributes, but we don't have the ability to describe nullable behavior of (bool ok, T result) Parse(string input) style methods with nullability attributes.

@jnm2 is correct that if (dict?.TryGetValue(out var value) == true) { ... } is the main motivating scenario of the feature.