Added: LDM Notes for May 19th, 2021

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-05-19.md

Agenda

1. Triage
   1. Checked operators
   2. Relaxing shift operator requirements
   3. Unsigned right shift operator
   4. Opaque parameters
   5. Column mapping directive
   6. Only allow lexical keywords
   7. Allow nullable types in declaration patterns
2. Protected interface methods

[MgSam]

Hmm, this still doesn't answer the question I asked on the thread linked in the design notes.

Will the change the LDM approved affect this scenario? If not, why does the below not work?

public interface IFoo
{
    public string Bar { get; internal set; }
}

public class Foo : IFoo
{
    public string Bar { get; internal set; } //Error - Non-public accessor "Bar.set" cannot implement accessor from interface IFoo
}

[AlekseyTs]

this makes doing what the code is intending here extremely cumbersome.

I think what code is intending can be done differently. I would say significantly less cumbersome:

interface IFoo
{
    public string Bar { get; internal set; }
}

public class Foo : IFoo
{
    string IFoo.Bar { get => Bar; set => Bar = value; }

    public string Bar { get; internal set;}
}

[MgSam]

It can't be, things that don't implement interface methods today would suddenly start implementing interface methods. It's a breaking change.

I'm having trouble envisioning how a class could start "accidentally" implementing an interface. Any class implementing an interface has to declare it does so. And if it fails to do so it won't compile. I'm assuming you're saying it would suddenly start binding to different methods/properties than it does today but couldn't you just keep the binding order the same so there is no backwards combability break? Or am I missing something else?

[theunrepentantgeek]

It can happen as things evolve over time - here's an example.

To begin, we have a regular interface:

public interface ICountable
{
    int Count { get; }
}

and it's implementation:

public class Crowd 
{
    // ... elided ...
    public int Count { get; private set; }

    protected async Task PrepareCount()
    {
        // ... elided ...
    }
}

Getting the count of a Crowd is complicated, so there's an async protected method that's used internally trigger it, with the goal of having the count available by the time Count is referenced.

All is good with the world ... until the interface is modified with the same feature ...

public interface ICountable
{
    int Count { get; }
    protected Task PrepareCount();
}

If we didn't have the Non-public members can be implemented only explicitly rule, that implementation detail of Crowd would now be hooked up to the interface, allowing it to be called from a lot more places.

This is dangerous - the semantics might work, or they might not.

[AartBluestoke]

This is dangerous - the semantics might work, or they might not.

but so is exposing it to your children, who may or many not use it in the correct way?
how is the parent interface exposing it more dangerous?

[theunrepentantgeek]

Think about blast radius.

A parent class often has a limited number of children, and in most cases the same developer (or at least the same team) is in charge of both.

An interface often has a very large number of implementations, and it's extremely common for other developers, other teams, other organisations, to implement them.