On the subject of error messages

[Nick Treleaven via Digitalmars-d]

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).