Why is CS9035 raised for records with primary ctor and required properties?

[julealgon]

I was making a few tests here with the new required modifier and noticed what I believe to be an incorrect emission of the CS9035 warning.

_ = new Y();
_ = new Y("value");
_ = new Y { Value = "value" };

readonly record struct Y(string Value)
{
    public required string Value { get; init; } = Value;
}

Severity	Code	Description	Line
Error	CS9035	Required member 'Y.Value' must be set in the object initializer or attribute constructor.	1
Error	CS9035	Required member 'Y.Value' must be set in the object initializer or attribute constructor.	2

The first warning works as I expect as I'm not providing Value on line1.
The second warning however looks wrong to me. I'm passing Value and using the same name to initialize my property

The docs don't seem to talk explicitly about required, but they mention this:

If the generated auto-implemented property definition isn't what you want, you can define your own property of the same name. For example, you may want to change accessibility or mutability, or provide an implementation for either the get or set accessor. If you declare the property in your source, you must initialize it from the positional parameter of the record. If your property is an auto-implemented property, you must initialize the property.

It would be even better if this was allowed though:

readonly record struct Y(required string Value)

However that just fails spectacularly with a completely unrelated compilation error:

I do understand I can just opt-out of the primary constructor, but that also strips away the automatically generated tuple deconstructor, which I do want.

To get the behavior I want, I'm forced to drop the primary constructor and add my own deconstruct logic.

[333fred]

This behaves exactly as intended, which is why primary constructor members are not defined as required by default.

[julealgon]

the compiler has no idea that the Value parameter in the constructor and the Value property are related.

What about the fact that I'm using the exact same name as in the ctor to set the property value? Wouldn't that be able to be used to check initialization happened?

[HaloFour]

What about the fact that I'm using the exact same name as in the ctor to set the property value? Wouldn't that be able to be used to check initialization happened?

What happens in the constructor is opaque to a consumer of that type.

[julealgon]

What happens in the constructor is opaque to a consumer of that type.

I can see how that applies to normal constructors where you have arbitrary logic inside, but for primary constructors though? Wouldn't the compiler be able to tell you are initializing the properties in that scenario?

Also, how can the compiler tell that you have initialized a readonly property today? What's different in checking whether a readonly member was assigned to vs a required one?

[HaloFour]

I can see how that applies to normal constructors where you have arbitrary logic inside, but for primary constructors though?

To an outside assembly the fact that the constructor was a primary constructor is entirely lost. Most of the metadata that would imply that the type is a record is too. There would need to be additional metadata that specifies that the constructor satisfies initialization of those required properties, which is exactly what SetsRequiredMembersAttribute does.

Also, how can the compiler tell that you have initialized a readonly property today? What's different in checking whether a readonly member was assigned to vs a required one?

You mean a property with an init accessor? All the compiler needs to do there is enforce that the only time that you can write to that member is during initialization. The compiler has no idea whether or not that member had already been written to within a constructor.

[TahirAhmadov]

I guess the question is, why aren't all primary ctors annotated with [SetsRequiredMembers]?

NVM, I figured it out.