LDM Notes for March 28th, 2022

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2022/LDM-2022-03-28.md

Agenda

1. Variable declarations under disjunctive patterns
2. Type hole in static abstracts
3. Self types

[alrz]

Within related statements: an if/else if, for example, but not in two unconnected if statements.

If we're going to go the extra mile to special case if/else, I think it's worth to consider making it synonymous to switch: allow variables of different types to share a name between if statements. Right now, this feels like a shortcoming in the current rules and and I'd expect it will be noticed as an annoying restriction.

[CyrusNajmabadi]

For context: https://openjdk.java.net/jeps/394

[HaloFour]

Your ideas are intriguing to me and I'd like to subscribe to your newsletter.

[alrz]

I somewhat wonder how bad of a break it would be to try and change the visibility rules to be flow scoped like Java did.

Reassignments turn to errors but if you have a field with the same name it could silently bind to that instead which is probably a no-go. Would it be too messy to do this only for multiply declared variables?

[HaloFour]

@alrz

Reassignments turn to errors but if you have a field with the same name it could silently bind to that instead which is probably a no-go.

I was thinking this, too. Changing the scoping rules entirely would be problematic and would contradict the design decisions for leaky scope in the first place. But perhaps some kind of "flow scoped shadowing" could be possible, where another local can be declared with the same name only if the first local is not definitely assigned. I think that's also likely to be a bit messy, especially from a spec point of view, but it might be "intuitive" enough to developers using the feature for that not to matter so much.

if (obj is string value) {
    // value is a string and definitely assigned here
}
else if (obj is int value) {
    // value is an int and definitely assigned here
}

// value is a string and not definitely assigned here?

This also feels totally orthogonal (and even possibly conflicting with) pattern variables in disjunctive patterns.

[alrz]

This also feels totally orthogonal (and even possibly conflicting with) pattern variables in disjunctive patterns.

It really is. I was suggesting to consider it separately to avoid the caveats involved in trying to make it a part of this proposal.

[iam3yal]

Can you extend redeclaration of variables to foreach too? so in the case of something like the following:

static IEnumerable<int> PrimeFactorImpl(int input, int prime = 2)
{
    // ...

    foreach (var returnedPrime in PrimeFactorImpl(input, prime))
    {
        yield return returnedPrime;
    }
 }

I could redeclare prime inside the foreach statement as opposed to come up with names such as returnedPrime.

[333fred]

That is general redeclaration, not anything related to patterns. This feature does not cover that.

[iam3yal]

Okay, thank you, I thought that it does cover it due to the if else if bit.

[333fred]

Only around usage with patterns though. Not outside of them.