Support static readonly values in switch expressions

[hach-que]

I've written a string-based enum library that allows you to define enumeration types like this:

class Example : StringEnum<Example>
{
    public static readonly StringEnumValue<Example> FirstValue = Create("first-value");
    public static readonly StringEnumValue<Example> SecondValue = Create("second-value");
    public static readonly StringEnumValue<Example> ThirdValue = Create("third-value");
}

You can then use the values like Example.FirstValue and parse them with Example.Parse("...") (inherited from StringEnum).

The problem is that matching against these (effectively constant) values is a pain. The following doesn't work, because static readonly fields aren't a constant expression, and as far as I can tell, there's no way for a user-defined type to ever work in a public const field. This means that you have to write this:

value switch
{
  var v when v == Example.FirstValue => /* ... */,
  var v when v == Example.SecondValue => /* ... */,
  _ => /* ... */
}

instead of what you really want to write, which is this:

value switch
{
  Example.FirstValue => /* ... */,
  Example.SecondValue => /* ... */,
  _ => /* ... */
}

[huoyaoyuan]

#6947 (comment)

[hach-que]

The ideal scenario for the particular pattern I'm trying to implement would be some form for constexpr support (to use C++ terminology).

The Create function that is used above returns a StringEnumValue<T> and the implementation looks like this:

protected static StringEnumValue<T> Create(string value)
{
    ArgumentNullException.ThrowIfNull(value);
    return new StringEnumValue<T>(value);
}

The implementation of StringEnumValue<T> is:

public sealed record class StringEnumValue<[DynamicallyAccessedMembers(
    DynamicallyAccessedMemberTypes.PublicProperties |
    DynamicallyAccessedMemberTypes.NonPublicProperties |
    DynamicallyAccessedMemberTypes.PublicFields |
    DynamicallyAccessedMemberTypes.NonPublicFields |
    DynamicallyAccessedMemberTypes.PublicMethods |
    DynamicallyAccessedMemberTypes.NonPublicMethods)] T> where T : StringEnum<T>
{
    internal StringEnumValue(string value)
    {
        ArgumentNullException.ThrowIfNull(value);
        Value = value;
    }

    public string Value { get; }

    public override string ToString()
    {
        return Value;
    }

    public static implicit operator string(StringEnumValue<T> v)
    {
        ArgumentNullException.ThrowIfNull(v);
        return v.Value;
    }

    // ... static methods Parse and TryParse ...
}

It is technically a type that is constant at compile time; it's just a strongly-typed wrapper around string.

If there was someway to tell the compiler that that value is a constant, or someway to define it's constant representation, then that would solve the problem without having to modify the limitations of switch (and a constexpr equivalent probably has broader benefit).

(Also a sidenote for constexpr: StringEnumValue<> can not be a struct because of the default parameterless constructor on all struct values. Any support for user-defined constant types in C# would need to be able to support an e.g. readonly class so that we don't get the side-effect of a public parameterless constructor on our constant types).

[HeinziAT]

@theunrepentantgeek

As soon as you do anything with the value, a side effect is possible.

Yes, of course. The background of my question was whether just reading a field---not doing anything with it, just reading the primitive value (in case of value types) or the object reference (in case of reference types)---could cause side effect. If reading it doesn't cause side effects, allowing field access in addition to constant expressions in patterns would help with the common use case of "static readonly values, which are used like constants, but are technically not constants".

But now that I think more about it, I realize that this idea is flawed, because we can't prevent the comparison (potentially overridden Object.Equals) from causing side effects. Oh, well.

[CyrusNajmabadi]

or the object reference (in case of reference types)---could cause side effect.

Definitely.

Consider reading some static readonly field. On first read the runtime will run the static constructor for that type, and run all the static initializers. Those absolutely can do anything, and can def have side effects.

[DavidArno]

@HeinziAT,

The key here is to having pure types. A pure type can itself only be composed of runtime-constant values and methods that are side-effect free. Values of pure types can themselves then be treated as runtime constants and could be used in constant patterns.

But I don't think there's currently anyone in the language team who is even exploring this space, much less championing the feature.

[HaloFour]

Most things can have side-effects, but the language already makes assumptions as to when certain values shouldn't have observable side-effects and I personally think it would be acceptable to follow similar rules here.

I personally think that patterns shouldn't attempt to be so clever as to rely on such a rule anyway. It's already possible for the LHS to have observable side-effects, and there are cases where out-of-order evaluation could result in unexpected errors at runtime.