Motivation
\nTo avoid Primitive Obsession.
\nIn 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
\n- \n
- A new argument modifier named
invariant. \n - Each parameter in a primary constructor with an
invariantparameter should have a corresponding staticValidatemethod. \n - A Validate method must be static and must correspond to an invariant parameter based on type and name. \n
Some examples:
\nThese are OK:
\na matching validate method with the same name and type of an invariant parameter
\npublic record struct Celsius(invariant float Value)\n{\n private static void Validate(float Value) => Invariant.Ensure(Value >= -273, \"cannot be less than absolute zero\");\n}public record struct Celsius(invariant float Value)\n{\n private static void Validate(float Value) => Invariant.Ensure(Value >= -273, \"cannot be less than absolute zero\");\n}public record struct WorkingAge(invariant int Value)\n{\n private static void Validate(int Value) => Invariant.Ensure(Value >= 14 && Value <= 66);\n}These are not OK - resulting in compilation errors
\nno corresponding Validate method found
public record struct Celsius(invariant float Value);validate method matches on name, but has a different type
\npublic record struct Celsius(invariant float Value)\n{\n private static void Validate(int Value) => Invariant.Ensure(Value >= -273, \"cannot be less than absolute zero\");\n}validate method matches no invariant parameter
\npublic record struct Celsius(invariant float Value)\n{\n private static void Validate(int Age) => Invariant.Ensure(Age >0);\n}I imagine invariant records to be very simple types containing just one parameter, and will primarily be used for wrapping primitives.
\nIf it gets more complicated than that, then the Validation idea falls down when multiple parameters are accepted:
compilation errors for methods with same signatures
\npublic record class Person(invariant string FirstName, string MiddleName, invariant string LastName)\n{\n private static void Validate(string FirstName) => Invariant.Ensure(!string.IsNullOrEmpty(FirstName), \"must have a value\");\n private static void Validate(string LastName) => Invariant.Ensure(!string.IsNullOrEmpty(LastName), \"must have a value\");\n}We could get around this by changing the Validate method to be an instance method which has access to the contents of the record:
\npublic record class Person(invariant string FirstName, string MiddleName, invariant string LastName)\n{\n private void Validate() => \n Invariant.Ensure(!string.IsNullOrEmpty(FirstName), \"must have a value\")\n .Ensure(!string.IsNullOrEmpty(LastName), \"must have a value\");\n}But I would prefer to restrict it to just one parameter; composite types could be made up from individual invariant records, e.g.
\npublic 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\n{\n public Invariant And(bool condition, [CallerArgumentExpression(\"condition\")] string? expression = null) =>\n Ensure(condition, expression);\n \n private static Invariant Ensure(bool condition, [CallerArgumentExpression(\"condition\")]string? expression = null)\n {\n if (!condition) throw new Exception($\"Invariant failed, expected: {expression}\");\n\n return default;\n }\n}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.
","upvoteCount":8,"answerCount":3,"acceptedAnswer":{"@type":"Answer","text":"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.
Invariant records #5574
-
Invariant records - value-constrained, non-defaultable recordsA proposal of an idea that I made in another thread. SummaryAn 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);
}MotivationTo 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 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 Proposal
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 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. 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 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 public primitive CustomerId(int Value) ...... where a 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. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 8 replies
-
|
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 [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) { }
} |
Beta Was this translation helpful? Give feedback.
-
This falls under compile time execution/contract. It's just a subtype of contract. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
Yes, it's going to be a fair amount of effort, but the language will be better and safer for it.
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
@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));
}
}
} |
Beta Was this translation helpful? Give feedback.
-
|
@mwisnicki - it is my proposal. @HaloFour is suggesting that such logic be implemented in source generators such as Vogen. In Vogen, a |
Beta Was this translation helpful? Give feedback.
-
|
Given example generates pseudo-records from structs. I don't think you can use 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 Or maybe streamline it even more: public record struct CustomerId(int Value)
{
init Value {
Invariant.Ensure(value > 0);
field = value;
}
} |
Beta Was this translation helpful? Give feedback.
-
Perhaps the language team should revisit this decision. Without language support it is entirely impossible to force non-default value type objects in an ironclad manner. |
Beta Was this translation helpful? Give feedback.
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
partialclass. I'd suggest that your source generator would remain the correct avenue to implement that logic.