On Saturday, 13 May 2017 at 14:41:50 UTC, Stanislav Blinov wrote:
>>template types(args...) {
>>    static if (args.length)
>>        alias types = AliasSeq!(typeof(args[0]), types!(args[1..$]));
>>    else
>>        alias types = AliasSeq!();
>>}
...
>>    foreach(i, T; types!args) {

typeof(args) ;-)

>>        static if (is(T == string)) {
>>            pragma(msg, format!"Argument %d is a string, which is not supported"
>>                    (i+1));

The problem with this approach is all the work required to convert existing code to use this style. Breaking the binary ops of the constraint into parts and reporting which failed (as the other replies mention) already would work with existing code, even if your approach can allow better messages. The binary ops part would immediately bring a huge improvement, despite any deficiencies.

> There are other alternatives, e.g. there's a DIP by Kenji Hara:
>
> https://wiki.dlang.org/User:9rnsr/DIP:_Template_Parameter_Constraint
>
> The approach I'm proposing is more flexible though, as it would allow to
> evaluate all arguments as a unit and infer more information (e.g. __traits(isRef, args[i]).
> Constraint on every argument won't allow the latter, and would potentially require writing more explicit overloads.

I think we should allow inline constraints*, non-inline constraints can still be used/combined. Inline constraints are easier to read and relate to what they affect, allowing any non-inline constraint to be considered as something with a wider scope (i.e., multiple arguments).

* template foo(R if isInputRange)

A side benefit is enum/alias/variable templates, they don't currently allow constraints in the grammar - they could have inline constraints without harming readability (presumably why constraints aren't supported).

On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:

> ...
>>>    foreach(i, T; types!args) {
>
> typeof(args) ;-)

Thanks :)

>>>        static if (is(T == string)) {
>>>            pragma(msg, format!"Argument %d is a string, which is not supported"
>>>                    (i+1));
>
> The problem with this approach is all the work required to convert existing code to use this style. Breaking the binary ops of the constraint into parts and reporting which failed (as the other replies mention) already would work with existing code, even if your approach can allow better messages. The binary ops part would immediately bring a huge improvement, despite any deficiencies.

That's not a problem. In cases where compiler-provided diagnostic is sufficient, nothing will need to be done.

>
> I think we should allow inline constraints*, non-inline constraints can still be used/combined. Inline constraints are easier to read and relate to what they affect, allowing any non-inline constraint to be considered as something with a wider scope (i.e., multiple arguments).

No matter if it's inline or trailing, it needs way, *way* better reporting than what we have now, so if you were to prioritize, which one would you solve first? :)

On 5/15/17 8:14 PM, Stanislav Blinov wrote:
> On Monday, 15 May 2017 at 20:55:35 UTC, Steven Schveighoffer wrote:
>> On 5/15/17 4:24 PM, Stanislav Blinov wrote:
>>> On Monday, 15 May 2017 at 19:44:11 UTC, Steven Schveighoffer wrote:
>>
>>>> It has to know. It has to evaluate the boolean to see if it should
>>>> compile! The current situation would be like the compiler saying
>>>> there's an error in your code, but won't tell you the line number.
>>>> Surely it knows.
>>>
>>> It "knows" it evaluated false. It doesn't know how to give user a
>>> digestible hint to make that false go away.
>>
>> I'm going to snip away pretty much everything else and focus on this.
>>
>> The compiler absolutely 100% knows, and can demonstrate, exactly why a
>> template constraint failed. We don't have to go any further, or make
>> suggestions about how to fix it.
>
> In complex constraints, that is not enough. When we have loops (i.e.
> over arguments, or over struct members), would it report the
> iteration/name?

Yes.

> Would it know to report it if `false` came several
> levels deep in the loop body?

Yes.

> Would it know that we actually *care*
> about that information? (*cough* C++ *cough* pages and pages of error
> text because of a typo...)

The idea is to give a preliminary rough report of which part of a boolean expression caused it to evaluate to false. Then you recompile with a flag to tell the compiler to do a deeper dive.

> When we have nested static ifs, it's important to see, at a glance,
> which parts of the combination were false. Again, if they're several &&,
> || in a row, or nested, pointing to a single one wouldn't in any way be
> informative.

Why not?

> When we have tests using dummy lambdas, are we to expect users to
> immediately extract the lambda body, parse it, and figure out what's wrong?

This is what you have to do today. The task has already been tried by the compiler, and the result is known by the compiler. Just have the compiler tell you.

>> Just output what exactly is wrong, even if you have to recurse into
>> the depths of some obscure template isXXX, and all it's recursively
>> called templates, I can get the correct determination of where either
>> my type isn't right, or the constraint isn't right.
>
> Please look over my isMovable example (I'm not sure if you caught it, I
> posted it as a follow up to my other reply). Suppose the `false` is
> pointed at by the compiler:
>
>>    else static if (is(T == struct) &&
>>            (hasElaborateDestructor!T || hasElaborateCopyConstructor!T)) {
>>        foreach (m; T.init.tupleof) {
>>            static if (!isMovable!(typeof(m)) && (m == m.init)) {
>>                return false;
>>                       ^
>>                       |
>>            }
>>        }
>>        return true;
>>    } else
>
> That is very, *very* uninformative. I don't know which member it was, I
> don't know which part of the conditional was false. I don't know which
> part of the conditional further up was true. Would the compiler know to
> tell me all that? Would it know to test further, to collect *all*
> information, so that I don't have to incrementally recompile fixing one
> thing at a time?

The compiler, and by extension your hand-written error checking, cannot know the true intention of the user. All it knows is you tried to do something that isn't supported. You have to figure out what is wrong and fix it. If that takes several iterations, that's what it takes. There is no solution that will give you all the answers.

In your example, the compiler would point at isMovable!S as the issue. Not super-informative, but is all it gives to prevent huge outputs. Then you tell it to print more information, and it would say that false was returned when the m member of type T is being checked, at which point you could get a stack trace of what values were at each level of recursion. Everywhere a boolean evaluated to true in order to get to the point where false is returned would be colored green, every time it was false, it would be colored red, and every time a short circuit happened, it wouldn't be colored.

For checking to see that "something compiles", it could identify the code that fails to compile. Again, the compiler has all this information.

This isn't any harder than debugging, in fact it should be easier, as all the compiler metadata is available in memory, and most of the information can be conveyed without having to poke around.

And it should be just about as good as your hand-written message. But always accurate, and instantly available to all existing constraints.

> Most importantly, as a user who sees this for the first time, I'd have
> no idea *why* those checks are there. I'd have no context, no grounds to
> base my reasoning on, so I'd either have to jump back to docs to see if
> I missed a corner case, or start spelunking code that I didn't write,
> which is always so fun... Thing is, the compiler is exactly in that
> position. It doesn't read the docs, ever :) It's always spelunking code
> written by someone else. It can't tell what the constraint, as a unit,
> is *actually* testing for. It doesn't care that we shouldn't
> destructively move structs with const members. So it wouldn't be able to
> tell me either. All it will do is report me that that false was returned
> on that line, and (hopefully), some additional info, like member type
> and name.

We can't hand-hold everyone. At some point you have to learn programming and debugging :)

-Steve

On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:

>> When we have tests using dummy lambdas, are we to expect users to
>> immediately extract the lambda body, parse it, and figure out what's wrong?
>
> This is what you have to do today. The task has already been tried by the compiler, and the result is known by the compiler. Just have the compiler tell you.

:) The compiler does not know what I'm checking for with that lambda. As far as the compiler is concerned, I'm interested in whether it compiles or not. It doesn't care what that means in the context of my constraint. Neither should the user.

> The compiler, and by extension your hand-written error checking, cannot know the true intention of the user.

The constraint *is* hand-written error checking. What I'm talking about is hand-written human-readable error messages :) It's not about knowing user intentions, it's about informing them why they made a mistake.

> All it knows is you tried to do something that isn't supported. You have to figure out what is wrong and fix it. If that takes several iterations, that's what it takes. There is no solution that will give you all the answers.

Hold on a second, I think there's a mixup in terminology here. A user (caller) of move() is not supposed to be interested in what particular evaluation chain caused the constraint to be false. I, as an author, declare a contract (constraint). I am not interested in user's intentions. I am interested that I'm being called correctly. When the user violates the contract, I must inform them they did so, by reporting *why* their argument does not satisfy me. Not by telling *how* I figured that out (compiler output), but by telling *what* is wrong with the argument (human-readable error message).

If the user does want to know how the constraint caught their mistake, they're free to inspect what the compiler outputs.

That is why (static) asserts have an optional string argument: to display a clean an readable error message, instead of just dumping some code on the user. The same thing, in my opinion, is needed for constraints.

> In your example, the compiler would point at isMovable!S as the issue. Not super-informative, but is all it gives to prevent huge outputs. Then you tell it to print more information, and it would say that false was returned when the m member of type T is being checked, at which point you could get a stack trace of what values were at each level of recursion. Everywhere a boolean evaluated to true in order to get to the point where false is returned would be colored green, every time it was false, it would be colored red, and every time a short circuit happened, it wouldn't be colored.

Or the user could just read a string "This overload cannot be called, because argument 1 (struct S) has a destructor and non-statically initialized const members". No "then", no printing more information, no stack traces. User is informed their type is wrong and *why* it is wrong. If they disagree, if they think there's a bug in the constraint, or if they're interested in how the constraint works, they're free to go through all the hoops you describe.

> We can't hand-hold everyone. At some point you have to learn programming and debugging :)

It's not about hand-holding. If I call a function from a foreign API, and the call does not compile, I'd want to know why it didn't compile, not what the author of the API did to make it not compile. I'd want to know what *I* must do to make it compile. Preferably without dissecting the API in order to find that out.

On Tuesday, 16 May 2017 at 11:20:57 UTC, Stanislav Blinov wrote:
> On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
>> The problem with this approach is all the work required to convert existing code to use this style.
...
> That's not a problem. In cases where compiler-provided diagnostic is sufficient, nothing will need to be done.

I don't understand. I thought you were proposing a new language feature (constraint expressions or pragma(overloadError))?

>> I think we should allow inline constraints*, non-inline constraints can still be used/combined. Inline constraints are easier to read and relate to what they affect, allowing any non-inline constraint to be considered as something with a wider scope (i.e., multiple arguments).
>
> No matter if it's inline or trailing, it needs way, *way* better reporting than what we have now, so if you were to prioritize, which one would you solve first? :)

My priority is (1) For the compiler to show which part of a constraint failed. Having inline constraints is lower priority, except:

* If it turns out to be hard to implement (1) then inline constraints would be easy to implement and at least allows finer grained error messages, but not for existing code - although perhaps it's possible for dfix to auto-update certain constraints in existing code.
* Inline constraints can probably be implemented in parallel by someone less able to do (1).

On Tuesday, 16 May 2017 at 14:00:51 UTC, Nick Treleaven wrote:
> On Tuesday, 16 May 2017 at 11:20:57 UTC, Stanislav Blinov wrote:
>> On Tuesday, 16 May 2017 at 09:04:32 UTC, Nick Treleaven wrote:
>>> The problem with this approach is all the work required to convert existing code to use this style.
> ...
>> That's not a problem. In cases where compiler-provided diagnostic is sufficient, nothing will need to be done.
>
> I don't understand. I thought you were proposing a new language feature (constraint expressions or pragma(overloadError))?

Oh. What I am proposing is add the possibility for the constraints to return a string in addition to the boolean. I am *not* proposing to remove the existing boolean checking. The compiler knows what type the constraint returns. If it's a boolean, nothing is changed. If it's a tuple, it could use the second value as a message (when it needs to output a message, i.e. when all overloads failed). pragma was just presented as an alternative. That's it :) Existing code should not break.

> My priority is (1) For the compiler to show which part of a constraint failed. Having inline constraints is lower priority, except:

From a user perspective, I would be interested in what the constraint failure *means*, not which part of it returned false. The constraint is there to prevent me from calling the function with the wrong types of arguments. The author decided which types are wrong. How the author checks for that is their business. Simply telling me I'm wrong does not help me stop being wrong. Showing me the "evidence" (constraint code) does not help me either, because the evidence is arbitrary, and in this case is a process, not statement of fact.

Steven argues that the compiler should be able to show the cause of failure. My counter-argument is that it's not helpful, because an isolated piece of the constraint does not necessarily reflect it's intent. Diagnostic generated from arbitrary code written by the constraint author will be even more confusing than telling nothing at all. Because it is code not written by the user, it may use names not provided by the user, etc. If I wrote a call foo(x), and then compiler tells me:

'property bar.front' is not defined

I'm going to take offense. I didn't pass any 'bar' to that function. Yet it's there because whoever wrote the constraint used a lambda there to test for something. Now I'd have to look at that, figure out what that 'bar' is, etc... Why should I? Why can't the constraint cleanly report what it's "false" result actually means?

On 5/16/17 9:54 AM, Stanislav Blinov wrote:
> On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:
>
>>> When we have tests using dummy lambdas, are we to expect users to
>>> immediately extract the lambda body, parse it, and figure out what's
>>> wrong?
>>
>> This is what you have to do today. The task has already been tried by
>> the compiler, and the result is known by the compiler. Just have the
>> compiler tell you.
>
> :) The compiler does not know what I'm checking for with that lambda. As
> far as the compiler is concerned, I'm interested in whether it compiles
> or not. It doesn't care what that means in the context of my constraint.
> Neither should the user.

You seem to be not understanding that a hand-written message of "needs to have member x" or something conveys the same information as the compiler saying "Error in this line: auto test = T.x"

Sure, it's not proper English. It gets the job done, and I don't have to instrument all my functions and template constraint helpers. I don't need to explode compile times, or debug why my messages don't match what actually happens.

>> The compiler, and by extension your hand-written error checking,
>> cannot know the true intention of the user.
>
> The constraint *is* hand-written error checking. What I'm talking about
> is hand-written human-readable error messages :) It's not about knowing
> user intentions, it's about informing them why they made a mistake.

hand-written == hand-compiled. That is, I translated what I think this boolean condition means into a human-readable format by hand. I could have got it wrong. Then a nice message is useless.

>> All it knows is you tried to do something that isn't supported. You
>> have to figure out what is wrong and fix it. If that takes several
>> iterations, that's what it takes. There is no solution that will give
>> you all the answers.
>
> Hold on a second, I think there's a mixup in terminology here. A user
> (caller) of move() is not supposed to be interested in what particular
> evaluation chain caused the constraint to be false. I, as an author,
> declare a contract (constraint). I am not interested in user's
> intentions. I am interested that I'm being called correctly. When the
> user violates the contract, I must inform them they did so, by reporting
> *why* their argument does not satisfy me. Not by telling *how* I figured
> that out (compiler output), but by telling *what* is wrong with the
> argument (human-readable error message).

The constraint tells the user why it doesn't work. There is no extra effort required. It's human readable (I know what isInputRange!R means). I don't need a specialized full-sentence message to understand that.

> If the user does want to know how the constraint caught their mistake,
> they're free to inspect what the compiler outputs.

And here is the problem. Your solution doesn't get us any closer to that. It's actually quite painful to do this today. When I have a type like this:

struct S
{
   int foo;
}

and the hand-written error message says: "Your type must be a struct that contains an integer property named 'foo'". How does that help me figure out what I did wrong? We can spend all day arguing over how nice this message is, but the truth is, what the constraint writer put in the constraints, and how the compiler is interpreting it, may be 2 different things. This helps nobody.

> That is why (static) asserts have an optional string argument: to
> display a clean an readable error message, instead of just dumping some
> code on the user. The same thing, in my opinion, is needed for constraints.

If assert(x == 5) would just print "Error: x == 4" automatically, we could eliminate most needs for a message.

You could solve this with a message, but again, this is a huge task to undertake on ALL code in existence, rather than fixing it all to a "good enough" degree that we don't need the messages. And it avoids the "human compiler" that is prone to error.

>> In your example, the compiler would point at isMovable!S as the issue.
>> Not super-informative, but is all it gives to prevent huge outputs.
>> Then you tell it to print more information, and it would say that
>> false was returned when the m member of type T is being checked, at
>> which point you could get a stack trace of what values were at each
>> level of recursion. Everywhere a boolean evaluated to true in order to
>> get to the point where false is returned would be colored green, every
>> time it was false, it would be colored red, and every time a short
>> circuit happened, it wouldn't be colored.
>
> Or the user could just read a string "This overload cannot be called,
> because argument 1 (struct S) has a destructor and non-statically
> initialized const members". No "then", no printing more information, no
> stack traces. User is informed their type is wrong and *why* it is
> wrong. If they disagree, if they think there's a bug in the constraint,
> or if they're interested in how the constraint works, they're free to go
> through all the hoops you describe.

That doesn't help me if the constraint author didn't put that message, or the constraint author put the *wrong* message, or wrote the constraint incorrectly.

-Steve

On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer wrote:
> On 5/16/17 9:54 AM, Stanislav Blinov wrote:
>> On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:
>>
>>>> When we have tests using dummy lambdas, are we to expect users to
>>>> immediately extract the lambda body, parse it, and figure out what's
>>>> wrong?
>>>
>>> This is what you have to do today. The task has already been tried by
>>> the compiler, and the result is known by the compiler. Just have the
>>> compiler tell you.
>>
>> :) The compiler does not know what I'm checking for with that lambda. As
>> far as the compiler is concerned, I'm interested in whether it compiles
>> or not. It doesn't care what that means in the context of my constraint.
>> Neither should the user.
>
> You seem to be not understanding that a hand-written message of "needs to have member x" or something conveys the same information as the compiler saying "Error in this line: auto test = T.x"

You are nitpicking again, or, at least, oversimplifying. I am understanding that perfectly. But we've both shown examples of constraints that are much more complex than just checking for one member. As in, the type needs to have these members and/or these properties. All of them. Or some of them. Or a set of combinations of them. With those specific traits, etc. It's not *just* "error in this line". It's "error in this line on this execution path with these conditions". And nowhere in sight is *what* all those checks are doing as a unit. Not individually, but in complex, all of them, in concert.
A fresh user of your code cannot know at a glance what all of them are doing, nor should they.

> Sure, it's not proper English. It gets the job done, and I don't have to instrument all my functions and template constraint helpers. I don't need to explode compile times, or debug why my messages don't match what actually happens.

If your messages don't match what actually happens, there's a bug in your constraint, simple as that. Which you should catch with tests.

>>> The compiler, and by extension your hand-written error checking,
>>> cannot know the true intention of the user.
>>

> hand-written == hand-compiled. That is, I translated what I think this boolean condition means into a human-readable format by hand. I could have got it wrong. Then a nice message is useless.

Eh? You *wrote* the constraint. You *know* what all of those tests mean. You didn't translate what you *think* the condition means. You wrote the condition, you *know* what it means. If you don't, you shouldn't be writing this constraint. The only way for you to "get it wrong" is to write a bug in the constraint. Or in the compiler.
You know that if you've just did is(typeof((T t) @safe {})) and it returned false, T's destructor cannot be called in @safe code. It's obvious, isn't it? Every D user knows that for sure.
There are obscure checks, that's the way the language works. There are cases when those obscure checks need to be cleanly explained. That is *all* that I'm proposing.

>> When the
>> user violates the contract, I must inform them they did so, by reporting
>> *why* their argument does not satisfy me. Not by telling *how* I figured
>> that out (compiler output), but by telling *what* is wrong with the
>> argument (human-readable error message).
>
> The constraint tells the user why it doesn't work. There is no extra effort required. It's human readable (I know what isInputRange!R means). I don't need a specialized full-sentence message to understand that.

*You* know what isInputRange means. This doesn't mean that all users do.
And do you know, beforehand, what all possible constraints in all possible libraries that you may use in the future mean, without looking at their code? No. No one does.

>> If the user does want to know how the constraint caught their mistake,
>> they're free to inspect what the compiler outputs.

> And here is the problem. Your solution doesn't get us any closer to that. It's actually quite painful to do this today.

Of course it is painful, that's the whole point of my proposal.

> When I have a type like this:
>
> struct S
> {
>    int foo;
> }
>
> and the hand-written error message says: "Your type must be a struct that contains an integer property named 'foo'". How does that help me figure out what I did wrong? We can spend all day arguing over how nice this message is, but the truth is, what the constraint writer put in the constraints, and how the compiler is interpreting it, may be 2 different things. This helps nobody.

It cannot be that way. Whoever wrote the constraint possesses knowledge about it's semantics. If they put wrong message there, then that's a bug, or they're a... well, not a very good person.

>> That is why (static) asserts have an optional string argument: to
>> display a clean an readable error message, instead of just dumping some
>> code on the user. The same thing, in my opinion, is needed for constraints.
>
> If assert(x == 5) would just print "Error: x == 4" automatically, we could eliminate most needs for a message.

You're taking overly simplified pieces of code and base your reasoning on them, while you know full well it's almost never this simple.

assert(x.veryBadlyNamedFunction == obscureStateObtainedFromElsewhere);

"Error: x.veryBadlyNamedFunction == 42"

Very helpful message.

> You could solve this with a message, but again, this is a huge task to undertake on ALL code in existence, rather than fixing

I seem to be expressing myself poorly, as I find I must repeat it the second time already: I never suggested to change any existing code. I suggested an *optional* mechanism of reporting errors.

> it all to a "good enough" degree that we don't need the messages. And it avoids the "human compiler" that is prone to error.

This again. No it does not. If there's a bug in the constraint, there is a bug in the constraint. Messages or no, it's all the same. Either it does what it's supposed to do, or it doesn't. Reporting the wrong message is a bug, as is returning false for compliant type, or true for malicious one.

>> stack traces. User is informed their type is wrong and *why* it is
>> wrong. If they disagree, if they think there's a bug in the constraint,
>> or if they're interested in how the constraint works, they're free to go
>> through all the hoops you describe.
>
> That doesn't help me if the constraint author didn't put that message, or the constraint author put the *wrong* message, or wrote the constraint incorrectly.

And again. If they wrote the constraint incorrectly, it's their bug. If they didn't put any message, compiler still should provide it's own diagnostics (better than today ones for sure).

On 5/16/17 2:29 PM, Stanislav Blinov wrote:
> On Tuesday, 16 May 2017 at 15:47:37 UTC, Steven Schveighoffer wrote:
>> On 5/16/17 9:54 AM, Stanislav Blinov wrote:
>>> On Tuesday, 16 May 2017 at 12:27:30 UTC, Steven Schveighoffer wrote:

>> When I have a type like this:
>>
>> struct S
>> {
>>    int foo;
>> }
>>
>> and the hand-written error message says: "Your type must be a struct
>> that contains an integer property named 'foo'". How does that help me
>> figure out what I did wrong? We can spend all day arguing over how
>> nice this message is, but the truth is, what the constraint writer put
>> in the constraints, and how the compiler is interpreting it, may be 2
>> different things. This helps nobody.
>
> It cannot be that way. Whoever wrote the constraint possesses knowledge
> about it's semantics. If they put wrong message there, then that's a
> bug, or they're a... well, not a very good person.

This is the only time I have issues. Most of the time, the constraint is straightforwardly simple and the problem is obvious just by looking at the constraint and the type.  When that's not the case, figuring out why the constraint doesn't seem to be doing what it says it's doing is the hard part.

This can be achieved any number of ways. The most straightforward and effective way is to have the compiler simply expose what it's doing.

>>> That is why (static) asserts have an optional string argument: to
>>> display a clean an readable error message, instead of just dumping some
>>> code on the user. The same thing, in my opinion, is needed for
>>> constraints.
>>
>> If assert(x == 5) would just print "Error: x == 4" automatically, we
>> could eliminate most needs for a message.
>
> You're taking overly simplified pieces of code and base your reasoning
> on them, while you know full well it's almost never this simple.
>
> assert(x.veryBadlyNamedFunction == obscureStateObtainedFromElsewhere);
>
> "Error: x.veryBadlyNamedFunction == 42"
>
> Very helpful message.

Not here to debate this "feature", but if it says what the return value was, and the name of the symbol it's checking against (and its value), then yes, combined with the usual stack trace it's incredibly useful. Most of the time, that's what I would normally write in the message, but that in itself isn't easy to do.

>> You could solve this with a message, but again, this is a huge task to
>> undertake on ALL code in existence, rather than fixing
>
> I seem to be expressing myself poorly, as I find I must repeat it the
> second time already: I never suggested to change any existing code. I
> suggested an *optional* mechanism of reporting errors.

No, I mean having the optional mechanism fixes nothing. Someone then has to go through all existing code and determine what the existing constraints are testing for, and then determine the best way to write the messages. That's not a trivial amount of work.

>> it all to a "good enough" degree that we don't need the messages. And
>> it avoids the "human compiler" that is prone to error.
>
> This again. No it does not. If there's a bug in the constraint, there is
> a bug in the constraint. Messages or no, it's all the same. Either it
> does what it's supposed to do, or it doesn't. Reporting the wrong
> message is a bug, as is returning false for compliant type, or true for
> malicious one.

There could be no bug in the constraint, but the message is misleading, wrong, or easy to misinterpret. It's adding another layer of potential issues.

-Steve