Allow type of an explicitly specified record property to differ from the corresponding primary constructor parameter

[tmat]

Currently, an optional parameter of a primary constructor of type T can only have default value default(T), but that's sometimes not the default value one might want to use. In a non-record type one could write code like so:

record struct T(int A, int B);

struct S
{
    public T P { get; init; }

    public S(T? p = null)
    {
        P = p ?? new T(A: 1, B: 2);
    }
}

This allows the call site of the constructor of S to omit argument for p and the reader of S.P then gets the customized default value.

With records though the equivalent code is considered invalid:

record struct T(int A, int B);

record struct S(T? P = null)
{
    public T P { get; init; } = P ?? new T(A: 1, B: 2);
}

error CS8866: Record member 'S.P' must be a readable instance property or field of type 'T?' to match positional parameter 'P'.

The above example could however compile into following:

internal struct S : IEquatable<S>
{
        public T P { get; init; }

	public S(T? P = null)
	{
		this.P = P ?? new T(A: 1, B: 2);
	}

	public void Deconstruct(out T P)
	{
		P = this.P;
	}

        // remaining generated methods unchanged
}

When matching primary constructor parameters to explicitly specified properties/fields in records the compiler would match by name only, ignoring the type of the property/field/parameter.

In general, the type of the parameter T1 might be entirely unrelated to the type T2 of the corresponding property/field. A valid conversion between these types must be performed in the explicitly specified initializer of the property/field.

[RikkiGibson]

I think we should enumerate the set of synthesized record members and rationalize what happens when the primary constructor type and the related property type are different in each case. Perhaps we would treat the primary constructor parameter as just being specific to construction, and use the property type in all other cases.

[RikkiGibson]

I happened across this issue while clearing my inbox. Pinging to say I'd be happy to review any proposal on this.

[HaloFour]

The primary constructor instructs the compiler as to the shape of the deconstruct method, which wouldn't make sense if the property could be different from the parameter type.

The OP suggests that the deconstructor would take the shape of the property matched nominally? I don't know if that sounds like a good idea. IMO wouldn't it be better for a record like this to declare a secondary constructor instead?

record struct S(T P)
{
    public S(T? P) : this(P ?? new T(A: 1, B: 2)) { }
}

[HaloFour]

I know it's just an example, but I'd like to note that a struct with a constructor with an optional parameter like that will not work the way you might expect it to. 😄

[RikkiGibson]

I know it's just an example, but I'd like to note that a struct with a constructor with an optional parameter like that will not work the way you might expect it to. 😄

since the evil (default) constructor will be picked instead? 😓

[HaloFour]

since the evil (default) constructor will be picked instead? 😓

Yup.