LDM notes for April 27 2020

[YairHalberstadt]

https://github.com/dotnet/csharplang/blob/master/meetings/2020/LDM-2020-04-27.md

Records: positional & primary constructors

[YairHalberstadt]

How will validators work with reflection?

Namely @jaredpar indicated in #3376 (comment) that he wanted existing reflection based frameworks to work with init properties as is.

However if validators are introduced, they will fail to call the validator after setting the initonly properties, possibly creating objects with an invalid state.

Is this of concern?

[Joe4evr]

However if validators are introduced, [reflection] will fail to call the validator after setting the initonly properties, possibly creating objects with an invalid state.

Is this of concern?

I brought up a potential solution to this over at runtime: dotnet/runtime#34978 (comment)
Of course, this does put the onus on the side of who owns the reflection to call this method. On the other hand, even if it takes reflection to do, having even one way of invoking an object's validator at any point in that object's lifetime may be a favorable thing to have.

[YairHalberstadt]

@Joe4evr that works for new code, but existing frameworks won't call it.

[jaredpar]

How will validators work with reflection?

The semantics of validators hasn't been designed yet, only the syntax. Hence the answer to this, and frankly how validators will work in standard C# code are unknown.

Is this of concern?

It's definitely one aspect that we are considering in this design. How and when validators run is a non-trivial design even for non-reflection code. Consider for example how the proposals around [Factory] methods allow for an object to be constructed and passed through several methods before it's finally considered done at which point it would be appropriate for a validator to execute.

[MgSam]

Is there a proposal for validators somewhere?

Also, have you guys yet discussed the proposed base(...) syntax for calling the base class constructor? (To avoid having to retype all the parameter names again that are identical)

[alrz]

The proposed way of resolving this is to require all user constructors to call the primary constructor

I suppose user constructors are also able to call each other via : this(). That still garantees that the primary constructor is eventually called.

For instance, constructors are a good way to provide default values for init-only properties that may be overwritten later. Validators are still useful for ensuring that the state of the object is legal after the init-only.

I think accessibility modifiers for none of these would make sense. The primary constructor is effectively as accessible as the type itself and the validator can't be referenced.

That said, I don't think we need to invent completetly alien syntax here, we already use static C() for static constructors.

class TypeName(int X, int Y) {
    public TypeName() {} // instance constructor
    static TypeName() {} // static constructor
    new TypeName() {} // primary constructor body
    init TypeName() {} // final initializer aka validator
}

[YairHalberstadt]

The primary constructor is effectively as accessible as the type itself and the validator can't be referenced.

Scala allows private primary constructors. They're useful for static factory methods.

[jaredpar]

@MgSam

Is there a proposal for validators somewhere?

No. This feature is very much in the stage of rough idea with a rough outline of the problems it could solve. It's not to the point where we have a doc detailing how it works across the scenarios that we generally care about.

Expectation is that we will be producing such a doc in the next month or two as we get into this part of records.

[qrli]

C# have a tradition of using () for functions, while properties do not. It is a visual clue I'm used to.

Now primary constructor and validator will change this... I don't know.

PS: what's the value of [CallerMemberName] when called in validator?

[theunrepentantgeek]

@qrli that visual clue is already less reliable that you might think:

public class C {
    
    public Action Trigger { get; set }
    
    public C()
    {
        Trigger = Nothing;
    }
    
    private void Nothing() { }
    
    public static void Main() 
    {
        var c = new C();
        c.Trigger = Log;
        c.Trigger();
    }

    private void Log() => Console.Writeline("Here");
}

I believe the syntax () literally means call-this-thing-on-the-left, nothing more. It might be a method, or it might be something else.

This is a technique I use regularly when creating interceptible types, especially ones implementing standard interfaces.