No counterpart for a validation rule whose logic is an arbitrary predicate

[woksin]

A validation rule whose logic is an arbitrary predicate has no counterpart in the language, so it is left out of the document entirely — the reader is not told that a rule exists at all, only that something was dropped.

In FluentValidation this is Must / MustAsync:

RuleFor(_ => _.OrgNumber)
    .Must(BeAValidOrganizationNumber)
    .WithMessage(_ => CustomersMessages.Approve_OrgNumberRequired);

The declarative rules — NotEmpty, MaximumLength, GreaterThan, Matches, Equal, EmailAddress and friends — all map cleanly. Must does not, because its logic is a method.

Why it is worth a construct

Measured while generating from a real production application: ~248 Must/MustAsync rules, plus ~37 more with other non-declarative shapes (NotEqual, InclusiveBetween, IsInEnum). Together they are the single largest remaining category of dropped content — around 285 rules, comfortably more than everything else the generator cannot express put together.

The consequence is not just missing detail. A command with three declarative rules and four Must rules currently reads as a command with three rules. The document understates how constrained the input is, and a reader has no way to tell the difference between "this field has no further rules" and "this field has rules that could not be written down".

Recovering the message helps a little — Cratis/Arc#2409 now writes $strings. keys — but a message with no rule to attach to still has nowhere to go.

Suggested direction

A way to state that a named rule applies without expressing its logic. Something like:

validate
  orgNumber
    not empty
    rule BeAValidOrganizationNumber message $strings.CustomersMessages.Approve_OrgNumberRequired

The name is statically available — it is the method or lambda the predicate resolves to — and it is meaningful to a reader in a way "a rule was dropped" is not. The document would then be honest about how many constraints a field carries, even where it cannot say what each one computes.

Points worth deciding:

• Whether an unnamed predicate (an inline lambda with no method to name) should be expressible at all, or should stay a diagnostic.
• Whether such a rule participates in anything the language does with rules elsewhere, or is purely descriptive.
• Whether the async variant needs distinguishing.

Related

• Validation language: conditional rules, cross-property operands, and state-based business rules #32 — validation conditions, cross-property and state rules. Adjacent, but distinct: that is about when a rule applies and what it may compare; this is about a rule whose logic cannot be expressed at all.
• Screenplay generation: recover validation messages from WithMessage(_ => Constant) lambdas (SP0016) Arc#2397 and Screenplay generation: emit $strings. keys for validation messages that resolve to resources Arc#2409 — where these were measured, and where the messages attached to them are now recovered.

[woksin]

Verified

Re-verified against main. ValidationRuleKind is a closed enum and ValidationRuleParser.OperandRegex enumerates the rule kinds it accepts — not empty|length ==|all >=|all >|matches|max|min|>=|<=|==|>|<. Anything outside that set produces Unknown validation rule '<op>', so there is no shape a named predicate could take today. A validate block is a flat list of one-line rules, each <property> <rule> [when <condition>] [message <text>] after #45.

Your framing of the consequence is the part I want to underline, because it is the strongest argument here and it is not about detail loss: a command with three declarative rules and four Must rules currently reads as a command with three rules. There is no way for a reader to distinguish "this field has no further constraints" from "this field has constraints that could not be written down". That is a document asserting something false, which is a different and worse problem than a document being incomplete — and it is the same failure mode #27 had with silently swallowed properties.

Design alternatives

1. A rule <Name> operand in the existing flat line.

validate
  orgNumber not empty                                       message "Organization number is required"
  orgNumber rule BeAValidOrganizationNumber                 message $strings.customers.orgNumberRequired
  orgNumber rule BeUnique when isNew == true                message "Already registered"

One new ValidationRuleKind, one new arm in OperandRegex, and everything the rule line already supports comes along unchanged — when from #45, message, $strings. keys, printer parity, the whole thing. No structural change to the block, so every existing document is untouched and the diff is small.

Cost: rule as a keyword inside a rule line reads a little flat, and the name sits in the operand position where every other rule has a value.

2. The nested form from your sketch — property header, indented rules.

validate
  orgNumber
    not empty
    rule BeAValidOrganizationNumber message $strings.customers.orgNumberRequired

Reads better when a property carries several rules, and it groups them the way a reader thinks about them. But it is a structural change to validate: the block becomes two-level, the parser has to distinguish a property header from a rule line (a bare orgNumber is currently an invalid rule, so it is detectable, but it is a real fork), and the printer has to choose between flat and nested for the same tree — which is exactly the kind of choice that breaks the print → compile → reprint guarantee unless one form is canonical. If we go nested, I would want nested to be the only printed form, and that churns every existing document's printed output.

3. Leave the logic out, but record that a rule exists — rule with no name.

validate
  orgNumber rule message "Organization number must be valid"

Honest about the count without pretending to name something. But the name is statically available in the case that matters, and BeAValidOrganizationNumber tells a reader more than the message alone. I would not ship this as the primary form.

Recommendation

Alternative 1 — rule <Name> as one more rule kind on the existing line. It is the smallest change that fixes the actual defect (the document understating how constrained a field is), it inherits when/message/$strings for free, and it does not touch the block's structure or any existing document's printed form.

On your three open questions:

• Unnamed predicates. Keep them a diagnostic, don't make them expressible. A rule with no name and no logic is indistinguishable from noise in the document, and the generator can legitimately say "this lambda has no name to recover". If it turns out inline lambdas dominate in practice, rule with no name (alternative 3) is a strictly additive follow-up.
• Does it participate in anything? Purely descriptive, and I would say so explicitly in the docs. The name is a reference into the implementation, not a declared entity — it should not be resolved against anything, unlike produces/executes/reads. Being clear about that now avoids someone later expecting rule X to resolve to a declared thing.
• Async. No. MustAsync is a realization detail of how the predicate is evaluated, and per the principle ratified in Declarative-first: the language must describe everything before code exists - 'file' must never be required #40 the document describes meaning, not execution. rule covers both.

Sequencing

Independent of the declarable-name work in #28/#29/#39 — precisely because rule <Name> should not resolve.

It does sit next to #32, and I would keep the boundary you drew: #32 is about when a rule applies and what it may compare; this is about a rule whose logic cannot be expressed. (a) and (b) of #32 landed in #45; (c), the state-based form, is blocked on #35 and #39. This issue is blocked on none of them and could land first.

The one thing worth deciding jointly is the flat-versus-nested question, because #32(c) will add another rule shape and the two should agree. If nested ever wins, it should win once, for all rule kinds.

@einari — the call I would like from you is flat (alternative 1) versus nested (alternative 2). I have argued for flat on round-trip grounds — nested would have to become the sole printed form and would churn every document's output — but nested genuinely reads better for a heavily constrained property, and if we want it, doing it before more rule shapes land is cheaper than after.

[woksin]

Implemented in #49, open for review and not merged — it is a language decision.

Went with the flat form (alternative 1 from my analysis above): rule <Name> as one more rule kind on the existing line, rather than the nested property-header form sketched in the issue. Reasoning is in the reviewer notes — chiefly that nested would make validate a two-level block and force the printer to pick one canonical form for the same tree, churning every existing document's printed output.

All three of your open questions are answered there too: an unnamed predicate is an error rather than expressible, the name is purely descriptive and resolves against nothing, and the async variant is not distinguished.