On Friday, 2 October 2015 at 12:15:13 UTC, Per Nordlöw wrote:
> I guess we only need on symbol name for `onAssertFailed` then instead of `assertBinOp` and `assertUnOp`, right?

And two overloads

Binary case:

    onAssertFailed(string op)(e1, e2, __FILE__, ...)

Unary case:

    onAssertFailed(string op)(e, __FILE__, ...)

I presume?

Because number of arguments to each overload will be fixed, right?

What about the case

assert(f(expr))
assert(symbol)

Should `op` be empty in that casesor should we use yet another overload

    onAssertFailed(e, __FILE__, ...)

for that case?

On Friday, 2 October 2015 at 12:27:11 UTC, Per Nordlöw wrote:
> What about the case
>
> assert(f(expr))
> assert(symbol)
>
> Should `op` be empty in that casesor should we use yet another overload
>
>     onAssertFailed(e, __FILE__, ...)
>
> for that case?

empty op for unary overload

On 10/02/2015 08:15 AM, Per Nordlöw wrote:
> On Friday, 2 October 2015 at 11:19:51 UTC, Andrei Alexandrescu wrote:
>> assert(e1 == e2)
>>
>> could be lowered into:
>>
>> {
>>   auto a = e1, b = e2;
>>   if (a == b) return;
>>   onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__,
>> __MODULE__);
>> }()
>
> So lowering is kind of like macro expansion for AST-nodes, then?

Not sure what you mean. The code up there will be replaced with the code down there :o).

> Is DMD clever enough to avoid trigger postblits for
>
>>   auto a = e1, b = e2;
>>   if (a == b) return;
>
> ? Or is that part of the question whether this will work?

Ah, interesting. There is a means in the compiler to generate ref variables, which is not accessible for user code. But perhaps that's not necessary if we do the lowering as such:

(auto ref a, auto ref b) {
  if (a == b) return;
  onAssertFailed!"=="(a, b, __FILE__, __LINE__, __FUNCTION__, __MODULE__);
}(e1, e2)

So that evaluates the two expressions and avoids creating copies for lvalues.

> I guess we only need on symbol name for `onAssertFailed` then instead of
> `assertBinOp` and `assertUnOp`, right?

Probably a judgment call. I'd start with one and see what happens.


Andrei

On 10/02/2015 08:27 AM, Per Nordlöw wrote:
> On Friday, 2 October 2015 at 12:15:13 UTC, Per Nordlöw wrote:
>> I guess we only need on symbol name for `onAssertFailed` then instead
>> of `assertBinOp` and `assertUnOp`, right?
>
> And two overloads
>
> Binary case:
>
>      onAssertFailed(string op)(e1, e2, __FILE__, ...)
>
> Unary case:
>
>      onAssertFailed(string op)(e, __FILE__, ...)
>
> I presume?

Sounds good.

> Because number of arguments to each overload will be fixed, right?
>
> What about the case
>
> assert(f(expr))
> assert(symbol)
>
> Should `op` be empty in that casesor should we use yet another overload
>
>      onAssertFailed(e, __FILE__, ...)
>
> for that case?

I'd say lower the same as (e !is 0) for numerics and (e !is null) for the others.


Andrei

On 10/02/2015 08:31 AM, Dicebot wrote:
> On Friday, 2 October 2015 at 12:27:11 UTC, Per Nordlöw wrote:
>> What about the case
>>
>> assert(f(expr))
>> assert(symbol)
>>
>> Should `op` be empty in that casesor should we use yet another overload
>>
>>     onAssertFailed(e, __FILE__, ...)
>>
>> for that case?
>
> empty op for unary overload

Even better. -- Andrei

On 2015-10-02 14:15, Per Nordlöw wrote:

> So lowering is kind of like macro expansion for AST-nodes, then?
>
> Is DMD clever enough to avoid trigger postblits for

The compiler just rewrites the AST.

-- 
/Jacob Carlborg

On Friday, 2 October 2015 at 14:08:06 UTC, Jacob Carlborg wrote:
> On 2015-10-02 14:15, Per Nordlöw wrote:
>
>> So lowering is kind of like macro expansion for AST-nodes, then?
>>
>> Is DMD clever enough to avoid trigger postblits for
>
> The compiler just rewrites the AST.

So you mean that no postblits are called and we should go with Andreis first lowering proposal?

On 10/02/2015 10:30 AM, Nordlöw wrote:
> On Friday, 2 October 2015 at 14:08:06 UTC, Jacob Carlborg wrote:
>> On 2015-10-02 14:15, Per Nordlöw wrote:
>>
>>> So lowering is kind of like macro expansion for AST-nodes, then?
>>>
>>> Is DMD clever enough to avoid trigger postblits for
>>
>> The compiler just rewrites the AST.
>
> So you mean that no postblits are called and we should go with Andreis
> first lowering proposal?

My first proposed lowering creates more copies than needed. My second one is therefore probably better, without resorting to compiler magic. -- Andrei

On Friday, 2 October 2015 at 14:54:08 UTC, Andrei Alexandrescu wrote:
> My first proposed lowering creates more copies than needed. My second one is therefore probably better, without resorting to compiler magic. -- Andrei

I update the spec. Could you take a look?

I'll update the operators, next.

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.

Should I remove all mentioning of extra compiler flags?