Invariant records

[SteveDunn]

Invariant records - value-constrained, non-defaultable records

A proposal of an idea that I made in another thread.

Summary

An invariant modifier on the parameters of a primary constructor and a corresponding validation method:

public record struct CustomerId(invariant int Value)
{
    // the argument name and type must match an argument name and type from the primary constructor
    private static void Validate(int Value) => Invariant.Ensure(Value > 0);
}

Motivation

To avoid Primitive Obsession.

In my domain, I want to make 100% sure that the domain ideas that I use are valid instances, so I use strongly-typed Value Objects, such as CustomerId instead of int.

I would like the language to allow me to express these constraints and I would like to prohibit any mechanism that could evade validation, e.g. through the explicit use of default(CustomerId).

Proposal

• A new argument modifier named invariant.
• Each parameter in a primary constructor with an invariant parameter should have a corresponding static Validate method.
• A Validate method must be static and must correspond to an invariant parameter based on type and name.

Some examples:

These are OK:

a matching validate method with the same name and type of an invariant parameter

public record struct Celsius(invariant float Value)
{
    private static void Validate(float Value) => Invariant.Ensure(Value >= -273, "cannot be less than absolute zero");
}

public record struct Celsius(invariant float Value)
{
    private static void Validate(float Value) => Invariant.Ensure(Value >= -273, "cannot be less than absolute zero");
}

public record struct WorkingAge(invariant int Value)
{
    private static void Validate(int Value) => Invariant.Ensure(Value >= 14 && Value <= 66);
}

These are not OK - resulting in compilation errors

no corresponding Validate method found

public record struct Celsius(invariant float Value);

validate method matches on name, but has a different type

public record struct Celsius(invariant float Value)
{
    private static void Validate(int Value) => Invariant.Ensure(Value >= -273, "cannot be less than absolute zero");
}

validate method matches no invariant parameter

public record struct Celsius(invariant float Value)
{
    private static void Validate(int Age) => Invariant.Ensure(Age >0);
}

I imagine invariant records to be very simple types containing just one parameter, and will primarily be used for wrapping primitives.
If it gets more complicated than that, then the Validation idea falls down when multiple parameters are accepted:

compilation errors for methods with same signatures

public record class Person(invariant string FirstName, string MiddleName, invariant string LastName)
{
    private static void Validate(string FirstName) => Invariant.Ensure(!string.IsNullOrEmpty(FirstName), "must have a value");
    private static void Validate(string LastName) => Invariant.Ensure(!string.IsNullOrEmpty(LastName), "must have a value");
}

We could get around this by changing the Validate method to be an instance method which has access to the contents of the record:

public record class Person(invariant string FirstName, string MiddleName, invariant string LastName)
{
    private void Validate() => 
            Invariant.Ensure(!string.IsNullOrEmpty(FirstName), "must have a value")
            .Ensure(!string.IsNullOrEmpty(LastName), "must have a value");
}

But I would prefer to restrict it to just one parameter; composite types could be made up from individual invariant records, e.g.

public record Employee(Name firstName, Name lastName, WorkingAge age);

I've used Invariant.Ensure in this discussion. Here's what I imagine it might look like:

public readonly struct Invariant
{
    public Invariant And(bool condition, [CallerArgumentExpression("condition")] string? expression = null) =>
        Ensure(condition, expression);
    
    private static Invariant Ensure(bool condition, [CallerArgumentExpression("condition")]string? expression = null)
    {
        if (!condition) throw new Exception($"Invariant failed, expected: {expression}");

        return default;
    }
}

I envisage this to be used simply as a means to wrap primitives. I'm aware that using records might encourage or infer more complex usage, but I'm also aware of the complexities of introducing a new concept into the language, such as primitive, e.g.:

public primitive CustomerId(int Value) ...

... where a primitive is like a record but with 1, and only 1, parameter in the primary constructor and with a corresponding Validate method.

I think anything that can be added to the language to make Value Objects easier to use and to steer people away from Primitive Obsession would be a good thing.

[SteveDunn]

I've recently been working on a source generator and analyzer that helps with non-default value objects. It's called Vogen (Value Object Generator). You decorate your struct or class and it generates record-like boilerplate code, but it tries hard to stop the user from evading validation or defaulting, e.g.

[ValueObject(typeof(int))]
public partial struct CustomerId {
    // optional
    private static Validation Validate(int value) => value > 0 
        ? Validation.Ok 
        : Validation.Invalid("Customer IDs must be a positive number.");
}

Usage looks like:

var id1 = CustomerId.From(123);

// error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
CustomerId c = default;

// error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
var c2 = default(CustomerId);

... and if we try to circumvent validation by adding other constructors, we get:

[ValueObject(typeof(int))]
public partial struct CustomerId {
    // Vogen already generates this as a private constructor:
    // error CS0111: Type 'CustomerId' already defines a member called 'CustomerId' with the same parameter type
    public CustomerId() { }

    // error VOG008: Cannot have user defined constructors, please use the From method for creation.
    public CustomerId(int value) { }
}

[huoyaoyuan]

These are not OK - resulting in compilation errors

This falls under compile time execution/contract. It's just a subtype of contract.

[En3Tho]

What about arrays, collections etc? I do not really see how this addresses that problem. What about structs containing other structs? FirstOrDefault pattern, TryGetValue pattern? There is more than one way to make a default value.

Struct wrappers overall have this problem and in my opinion classes in .Net give a better protection if I can name it like this. In case of not using unsafe or runtimehelpers or whatever magic things it's either valid or it is a null. So in a sense even a null is a safer value than default struct.

[SteveDunn]

What about arrays, collections etc?

Yes, it's going to be a fair amount of effort, but the language will be better and safer for it.

What about structs containing other structs? FirstOrDefault pattern, TryGetValue pattern?

Good points. It's going to be very tricky.

Would I be wrong in sensing that you think this isn't a problem that can be solved? Or perhaps a problem that doesn't need to be solved?

My opinion, after many years in the industry, is that this lack of safety in the language makes the intent of developers' C# code harder to understand. All problems aside (the ones you mention above), having immutable/invariant records will greatly assist in understanding this intent.

[HaloFour]

The point I believe is that the problem doesn't lie in the language, it lies in the runtime. There's little that the language can do to prevent the zero-initialization behavior in a large number of scenarios.

The LDM has been considering non-defaultable struct types as a separate feature. I think that's a blocker for consideration of this proposal. I also think that this proposal is much too opinionated to be considered on its own and that filling in all of the invariant validation behavior would remain a feature of your source generator and not the compiler.

[SteveDunn]

I'd prefer to see the language try to stop zero-initialization. There's quite a few common cases where it could achieve this.

Re. opinionated: yes, in my source generator, it needs to be opinionated due to missing support in the language. Instead of Validate, we could have another type of constructor. For instance 'D' has invariant which seems similar to a constructor, but is just for validation.

I think non-defaultable struct types are just half the story. If we can get that half through, then great! But I think that these two concepts naturally belong together and that if they were considered together, we'd end up with a nicer syntax.

[HaloFour]

Support for validation is missing in records because the language team decided that such policy should not be built into the language, but provided through external means like source generators. This is why all of the members otherwise auto-generated by records can also be provided through explicit code in a partial class. I'd suggest that your source generator would remain the correct avenue to implement that logic.

[mwisnicki]

@HaloFour how do you propose the generated code to look like so that user is always validated through Validate method?

partial record User(string name)
{
    void Validate()
    {
        if (name.Length > 10)
        {
            throw new ArgumentException("Too long", nameof(name));
        }
    }
}

[SteveDunn]

@mwisnicki - it is my proposal. @HaloFour is suggesting that such logic be implemented in source generators such as Vogen.

In Vogen, a Validate method is called if the user provides one, as explained more fully in this quick tutorial.

[mwisnicki]

Given example generates pseudo-records from structs. I don't think you can use with with them?
And what's the point of having records in the language :/

As for your proposal I think a better syntax would be with simplified init:

public record struct CustomerId(int Value)
{
    int Value {
       init {
          Invariant.Ensure(value > 0);
          field = value;
       }
    }
}

So basically make get/set optional.

Or maybe streamline it even more:

public record struct CustomerId(int Value)
{
    init Value {
      Invariant.Ensure(value > 0);
      field = value;
    }
}