On Friday, 2 October 2015 at 00:05:33 UTC, Timon Gehr wrote:
On 10/02/2015 01:33 AM, Andrei Alexandrescu wrote:
On 10/01/2015 06:41 PM, Timon Gehr wrote:
On 09/30/2015 03:10 PM, Andrei Alexandrescu wrote:
I encourage making assert smarter seeing (a) it's already
used
everywhere so the benefits will come for free and (b) it's
a built-in.
-- Andrei
About (b): I'm surprised to see that you seem to have so
fundamentally
changed your attitude towards magical semantics for built-ins.
I haven't - I still think making "assert" a built-in and
ascribing a
keyword to it was a minor mistake. But then that sail has
shipped, so
let's make the best use of the situation. -- Andrei
Ok, but if assert gets special error printing capabilities that
are not available at the same level of convenience to e.g.
enforce, then this is a roughly analogous situation to having
e.g. B[] : const(A)[] for B : A, which cannot currently be
simulated in the library in a satisfactory way. Those
situations usually add friction. They tend to result in
frustration and often culminate in proposals for new, often
ad-hoc language features. IMHO, there ought to be a better way,
but I don't have a very strong opinion about this particular
case.
On the other hand, changing the language to provide access to
this as library would require something macro like, and both
Andrei and Walter seems to be really against it.
As we are on assert, 2 things :
- Before considering adding more magic, can we get line numbers
in stack traces ? It really seems to me like improving the
message no stack trace is available is not focusing on impact.
- assert already have a fair amount of magic, notably assert(0)
change the way control flow works. Having it as an expression is
making everything very convoluted for no reason.
