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