Proposal: restrictions for get accessor for interfaces and abstract classes

[iPilot]

Description

Additional constraint for property get accessor:

expr property accessor:

• Restricts the property accessor to be expression bodied, preventing it from having a set accessor when overridden and from setting a value in the constructor phase
• Necessity is debatable

Updated: impossible to implement - discarded

const expr property accessor:

• Restricts the property accessor to be expr and to be evaluated only using constants expressions, including other const expr properties what makes the property accessor aligned with existing constants behavior

Updated: simply const literal could be used for that purpose

Examples

public abstract class BaseClass
{
    public abstract string Type { const expr; }
}

public sealed class A : BaseClass
{
    public override string Type => "type_a";
}

public interface IBaseInterface
{
    string Type { const expr; }
}

public sealed class B : IBaseInterface
{
    public string Type => "type_b";
}

Intended usage

Initially idea grows from JSON polymorphic serialization / deserialization. Currently, JsonPolymorphicAttribute requires for each type metadata be passed to JsonDerivedTypeAttribute attribute. That metadata access requires discriminator value to be declared either as a constant field in derived class or somehow else. Additionally, current implementation behaves very weird when combination of custom naming policy, Enum as discriminator and custom converter are used. const expr would allow to add a compile-time validation for a such polymorphic hierarchy as the base class would demand explicitly implement property used as polymorphic discriminator. Also, such properties could be attributed with custom JSON converter.

I'm not sure, but maybe Native AOT compilation could benefit from this way of metadata delivery.

[colejohnson66]

If you need a discriminator, look at JsonSubTypes

[TahirAhmadov]

I think should be part of the overall const methods initiative, #2379

[iPilot]

Const methods initiative is way more complex. Right now, compiler is already capable to convert expression bodied accessor to method returns constant value. The proposal is only about the contract model, more like an extension of static abstract interface member, that restricts implementation in classes implement interface. Nothing stops me from doing this:

    public interface IA
    {
        static abstract string A1 { get; }
    }

    public class A : IA
    {
        public static string A1 { get; set; } = "string";
    }

but in some cases, I want to limit implementation by contract.

[HaloFour]

I'm not sure I understand the purpose. As a contract invoked via virtual call whether or not the member is implemented with a const expression doesn't really matter, it's not like the compiler or runtime can inline or fold the invocation. As for the discriminator use case, that is something much better served through attribute metadata as that can be read via reflection. The method body isn't, regardless of whether or not that body is a const expression.

[iPilot]

Well, in my head it should work similar to init accessor and be either:

• a get accessor with constant backing field what will automatically cause compilation error when field is being initialized with something that is not constant
• a get accessor method that returns constant value, and compiler already knows how to detect constant values

Second option is possible because currently expression bodied get-only accessor is converted to method without backing field returns constant value or other method or property accessor call result.

All scenarios below should work fine:

public interface IA
{
    string P1 { const expr; }
    string P2 { const expr; }
    string P3 { const expr; }
}

public class A : IA
{
    public string P1 => "string";

    public string P2 { const expr; } = "string";

    public string P3
    {
        [ConstReturn] // it could be an attribute instructs compiler what value are possible to be returned
        get
        {
            return "string"; // const token
        }
    }
}

[HaloFour]

and compiler already knows how to detect constant values

Only when referencing a const directly, not through a method invocation. Only the runtime might get involved in that kind of optimization. And given any call through IA is a virtual call, that can't be inlined as the actual type is not known.

it could be an attribute instructs compiler what value are possible to be returned

Then why does it need to be a member at all? IMO, this solution does not work well for discriminators, especially since that metadata really belongs on the base type, not the derived types. And given discriminated polymorphism is already a solved problem, I don't see any utility to adding specific language support for it.

[iPilot]

Then why does it need to be a member at all?

To guarantee that derived class has necessary for serialized representation property
To allow attribute such properties by custom converters and ease naming policy applying.

And given discriminated polymorphism is already a solved problem

Right now, using enum as discriminator is very painful, although it is a very natural way to do it, especially when string enum representation is desired.

[HaloFour]

To guarantee that derived class has necessary for serialized representation property
To allow attribute such properties by custom converters and ease naming policy applying.

Members don't need to exist for that. The serialization library can use the metadata information it already has to emit the data into the wire format to include the discriminator without requiring that the class being serialized duplicate that same data.

Right now, using enum as discriminator is very painful, although it is a very natural way to do it, especially when string enum representation is desired.

Why is it painful? Using enum values with attributes is trivial.

All of these issues sound like they are better solved by serialization libraries and entirely independently from the language.