On Thursday, 1 October 2015 at 11:51:29 UTC, Per Nordlöw wrote:
> On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
>> As a follow-up to
>>
>> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495
>
> I added a long comment about a new more flexible solution to this problem:
>
> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144701371

Would `onAssertFailed` have an implementation in druntime? If one is included with D after this DIP is implemented, how would one override the default behaviour? Do I understand it correctly that `assert(a == b)` and `assert(a != b)` would call different overloads? The reason I ask about that last one is because there's no overloading of `!=` in D.

Atila

On Monday, 26 October 2015 at 15:17:37 UTC, Atila Neves wrote:
> Would `onAssertFailed` have an implementation in druntime?

Yes, that's my plan.

> If one is included with D after this DIP is implemented, how would one override the default behaviour?

> Do I understand it correctly that `assert(a == b)` and `assert(a != b)` would call different overloads?

That depends on how we want this to work.

> The reason I ask about that last one is because there's no overloading of `!=` in D.
>
> Atila

Ahh, good catch.

Eventhough compiler rewrites

    X != Y

into

    !(X == Y)

and we cannot explicit overload opBinary!"!=" there is nothing stopping us allowing

    onBinaryAssert!"!="

in the rewriter.

I'll update

http://wiki.dlang.org/DIP83

with a proposed solution for `!=`-lowering.

On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
> On Monday, 26 October 2015 at 15:17:37 UTC, Atila Neves wrote:
>> Would `onAssertFailed` have an implementation in druntime?
>
> Yes, that's my plan.
>
>> If one is included with D after this DIP is implemented, how would one override the default behaviour?

I haven't thought about that in detail. One way would be to have a default implementation in druntime, say in `core.assert` that triggers pretty pretting when imported. For this work in a convenient way, it could be convenient to move logic from std.conv to, say, `core.conv`. `core.assert` could then import `core.conv` in order to reuse toString-conversion logic for, say, builtin types and types that have the member `string toString`.

Maybe we need to propose a set of alternatives and do a vote about how to solve this.

On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
> I'll update
>
> http://wiki.dlang.org/DIP83
>
> with a proposed solution for `!=`-lowering.

Update along with other changes...done.

On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
> Eventhough compiler rewrites
>
>     X != Y
>
> into
>
>     !(X == Y)
>
> and we cannot explicit overload opBinary!"!=" there is nothing stopping us allowing
>
>     onBinaryAssert!"!="
>
> in the rewriter.

Correction:

there is nothing stopping us from allowing

    onAssertFailed!"!="

to be defined as long as the compiler lowering logic can do the correct rewrite.

On Monday, 26 October 2015 at 19:17:13 UTC, Nordlöw wrote:
> there is nothing stopping us from allowing
>
>     onAssertFailed!"!="
>
> to be defined as long as the compiler lowering logic can do the correct rewrite.

For further details, see also:

http://wiki.dlang.org/DIP83#Non-Equality_Operator_Lowering

On Monday, 26 October 2015 at 17:50:13 UTC, Nordlöw wrote:
> On Monday, 26 October 2015 at 17:36:37 UTC, Nordlöw wrote:
>> On Monday, 26 October 2015 at 15:17:37 UTC, Atila Neves wrote:
>>> [...]
>>
>> Yes, that's my plan.
>>
>>> [...]
>
> I haven't thought about that in detail. One way would be to have a default implementation in druntime, say in `core.assert` that triggers pretty pretting when imported. For this work in a convenient way, it could be convenient to move logic from std.conv to, say, `core.conv`. `core.assert` could then import `core.conv` in order to reuse toString-conversion logic for, say, builtin types and types that have the member `string toString`.
>
> Maybe we need to propose a set of alternatives and do a vote about how to solve this.

I think druntime should at least be mentioned in the DIP.

Atila

On Tuesday, 29 September 2015 at 21:02:42 UTC, Nordlöw wrote:
> As a follow-up to
>
> https://github.com/D-Programming-Language/phobos/pull/3207#issuecomment-144073495
>
> I starting digging in DMD for logic controlling behaviour of assert(), especially whether it's possible to add automatic printing of `lhs` and `rhs` upon assertion failure if `AssertExp` is a binary expression say `lhs == rhs`.
>
> After grepping for `AssertExp` the only possible place I could think of was
>
> ToElemVisitor::visit(AssertExp *ae)
>
> inside
>
> elem *toElem(Expression *e, IRState *irs)
>
> in file e2ir.c.
>
> Questions:
>
> 1. Is this the right place where this lhs-rhs-printing logic should be added? If so could somebody tell me how to make this happen?
>
> 2. Is it possible to from within DMD generate expressions that do
>
> `import std.stdio : write`
>
> and then calls write on the `lhs` and `rsh`...or this a completely wrong approach to solving this problem?

More thoughts on this: what about ranges and testing for equality? It would be helpful if either this DIP made the compiler recognise and deal with `std.algorithm.equal` differently or recognise that on one or both sides of `==` there's a range.

I'm thinking of all the different `shouldXXX` functions I wrote for unit-threaded. Equality is by far the most common thing to assert on in a test, but there are other useful ones that need to be considered. Two that come to mind right now are asserting that a range contains an element and that two ranges are the same ignoring ordering.

For the former, `assert(range.canFind(elt))` would be hard to deal with in this DIP. I don't see a better way, however, since `in` only works for AAs.

For the latter... I don't know either.

Atila