LDM Notes for March 30th, 2022

[333fred]

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

Agenda

1. Definite assignment in struct constructors calling : this()
2. file private accessibility

[Joe4evr]

Here's a case I can think of for file being a modifier to accessibility in general (option 3):

public partial class MyCollection<T> : IEnumerable<T>
{
    public Enumerator GetEnumerator() => new(this);

    public struct Enumerator : IEnumerator<T>
    {
        // other files in this project shouldn't access this ctor,
        // but it needs to be internal at least for the outer type to use
        file internal Enumerator(MyCollection<T> collection) //...... 
    }
}

[RikkiGibson]

I think that the suggested design for option 2 (single new accessibility level) was supposed to be the most permissive one, which would make it equivalent to 'file internal', to my understanding.

[333fred]

That was my understanding as well.

[alrz]

1. File accessibility modifier #5969 as is.
2. file or fileonly as a new accessibility.
3. file is allowed to be combined with any existing accessibility.

Ability to combine file accessibility with others could encourage a new level of "abstraction": per file, which to be honest I don't really see as a good thing. Is this really expected to be used outside SGs? If not I'd suggest hidden modifier as an indication that it's not intended to be used in user code.

[CyrusNajmabadi]

Is this really expected to be used outside SGs

Yes. A core use case for me is normal user code.

[TahirAhmadov]

For structs, I will re-iterate - please, please try to make structs work like classes - taking into account breaking existing code, like it was noted, using fix suggestions, etc. I understand why C# 1 went with parameterless struct ctors being always available, but it felt weird back then, and today, with default(T) being available, it's really strange.
I'm perfectly happy with option 6; do option 4 now, but have a plan to slowly transition to option 6. If it's a struct like Point, which has no explicit parameterless ctor, and IDE encounters new Point(), it should change it to default(Point). That suggestion should be rolled out as soon as possible.
Then, we can make that a warning in a future version, like C#11.

[jnm2]

Now, new S() suddenly returns something other than default(S). This means you have to modify that site to expect these changes.

@TahirAhmadov This is actually not true and it's exactly why I was saying I do use new S() in this case. I do not have to modify the usage site; all it takes is a recompile. Of course you can't change S without getting a binary behavioral break, but that's not a concern in the cases I'm thinking of.

[TahirAhmadov]

Now, new S() suddenly returns something other than default(S). This means you have to modify that site to expect these changes.

@TahirAhmadov This is actually not true and it's exactly why I was saying I do use new S() in this case. I do not have to modify the usage site; all it takes is a recompile. Of course you can't change S without getting a binary behavioral break, but that's not a concern in the cases I'm thinking of.

You don't have to modify the callsite from a compilation perspective, yes. But you definitely want to modify it (or at least review it). If the same line of code has a different outcome after a recompile, that change can have repercussions and should not be ignored.

[jnm2]

I believe I can be sure I won't want to modify or review it so long as I use new S() ahead of time. Cases aren't coming to mind where this could be a pitfall.

[TahirAhmadov]

That's fine - you mentally analyzed your particular use case and it makes that new S() starts doing something different than before, and the usage site can continue working as expected. However, that's your use case only. As a general rule, it's a very dangerous way to make changes.

[RikkiGibson]

FWIW, if I introduced such a constructor, I might be inclined to "find all references" and at least skim through them.