On 10/01/2015 01:19 PM, Per Nordlöw wrote:
> On Thursday, 1 October 2015 at 14:37:55 UTC, Andrei Alexandrescu wrote:
>> Whoever wants to work on better assert expression printing: make sure
>> you specify which grammar constructs are supported, and how the parts
>> involved are printed. Expressing semantics via lowering would be
>> great. Write a DIP, discuss, implement. I'll have your six.
>>
>>
>> Andrei
>
> A first version:
>
> http://wiki.dlang.org/DIP83

A good start. Few thoughts:

* I don't think we need a new flag, just make the new behavior work.

* Should the lowering happen only on the function called if the assertion actually fails? Then no more need for laziness and other complications.

* Extend to other expressions (!=, ordering etc).


Andrei

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.

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

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 Thursday, 1 October 2015 at 23:33:39 UTC, Andrei Alexandrescu wrote:
> 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

Wouldn't that mean that every file that uses unit tests would have to import std.assert or something? So pretty much every file would be importing it anyway.

On Friday, 2 October 2015 at 00:25:18 UTC, jmh530 wrote:
> Wouldn't that mean that every file that uses unit tests would have to import std.assert or something? So pretty much every file would be importing it anyway.

It could, for example, still be in object.

 — David

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.

On Friday, 2 October 2015 at 00:33:13 UTC, David Nadlinger wrote:
> On Friday, 2 October 2015 at 00:25:18 UTC, jmh530 wrote:
>> Wouldn't that mean that every file that uses unit tests would have to import std.assert or something? So pretty much every file would be importing it anyway.
>
> It could, for example, still be in object.

Yeah. We already have that with several symbols (e.g. size_t and string), and arguably we should do it with a few others (like the range primitives for arrays). So, if we'd made new and assert into library functions instead of built-ins like we arguably should have been, then they'd probably be in object.d, but that shipped has long since sailed.

- Jonathan M Davis

On Thursday, 1 October 2015 at 19:04:51 UTC, Andrei Alexandrescu wrote:
> * I don't think we need a new flag, just make the new behavior work.

So you mean that extra diagnostics should kick in when extra overloads are made visible via import of, for instance, `core.assert`?

> * Should the lowering happen only on the function called if the assertion actually fails? Then no more need for laziness and other complications.

Could explain what you mean by *lowering*, please?

I'm currently unsure whether
    in L lhs
or
    lazy L lhs

should be used and whether or not we should use
    version(assert)

See the added example at
http://wiki.dlang.org/DIP83

> * Extend to other expressions (!=, ordering etc).

How should we categorize expressions? Like this
- Unary: assert(x UNOP y)
- Binary: assert(x BINOP y)
- Function Calls: assert(f(x,y))
- Other: assert(x)

Does it suffice to just mention these or should I be explicit exactly about which operators for each category that should be included?

On Thursday, 1 October 2015 at 17:33:51 UTC, Jack Stouffer wrote:
> Bikesheading: could you change "being" in "([1,2,3][2] being 3) != ([1,2,4][2] being 4)" and the other examples to "is"?

Done.