Re: assert with format considered harmful
Let me point out the elephant in the room as well.
On 02/25/2017 10:34 PM, Ali Çehreli wrote:
> // In this case a %s is forgotten but it could be any other trivial
> error.
> assert(i == 42, format("Bad parameter:", i));
In addition to the current dangerous behavior of assert, there is the
philosophical argument whether the program can do anything at all after
an assert. Like many others, our friend Chris Wright thinks so:
http://forum.dlang.org/post/o6u5j5$1gnf$1...@digitalmars.com
On the other hand, I, like many others, have apparently been
hypocritical every time I attempted to generate a message for assert.
That's wishful coding indeed. :)
How about this rule: The message generation code must be
- be nothrow
- have no side-effects, which means the message that it generates must
be written into a pre-allocated space, without going out of bounds (how
to control this?)
- nogc (I think this is implied from the previous two)
The more I learn and understand about computing the more it becomes
crazy. :)
Ali
Re: assert with format considered harmful
On Sunday, February 26, 2017 11:13:47 Nick Sabalausky via Digitalmars-d wrote: > Yea. Six years ago, assertPred was written for Phobos and rejected > because it was decided it was better for assert to just gain that > functionality built-in...which a full six years later, never happened. > Letting perfect be the enemy of the good, at its golden finest. Well, to make matters more entertaining, it was later decided that it was unreasonable to alter assert to print the extra information that assertPred had. So, it's not even a case of no one doing it. It's a case of it being rejected, leaving us with neither solution. - Jonathan M Davis
Re: assert with format considered harmful
On Sunday, 26 February 2017 at 16:13:47 UTC, Nick Sabalausky (Abscissa) wrote: On 02/26/2017 02:17 AM, Seb wrote: [...] Yea. Six years ago, assertPred was written for Phobos and rejected because it was decided it was better for assert to just gain that functionality built-in...which a full six years later, never happened. Letting perfect be the enemy of the good, at its golden finest. Well if it makes you feel any better, I had a similar experience last summer: https://github.com/dlang/phobos/pull/4323 (the same opinion prevailed)
Re: assert with format considered harmful
On 02/26/2017 02:17 AM, Seb wrote:
On Sunday, 26 February 2017 at 06:34:07 UTC, Ali Çehreli wrote:
So, obviously, assert message generation is not lazy. This is a WAT!
for me but perhaps there is a good reason for it.
FWIW imho we shouldn't need to write such messages at all.
It shouldn't be to difficult to lower `assert (a BINOP b)` into sth. like:
(auto ref a, auto ref b) {
if (a BINOP b) return;
onAssertFailed!"BINOP"(a, b, __FILE__, __LINE__, __FUNCTION__,
__MODULE__);
} (e1, e2);
with onAssertFailed being a nice pretty-printer in the direction of:
assert([1,2,3] == [1,2,4]); // ERROR: ([1,2,3][2] is 3) != ([1,2,4][2]
is 4)
struct A { int x, y; }
auto a = A(1,2);
auto b = A(1,3);
assert(a == b); // ERROR: (a.y is 2) != (b.y is 3)
This idea is formally known as DIP83:
https://wiki.dlang.org/DIP83
Yea. Six years ago, assertPred was written for Phobos and rejected
because it was decided it was better for assert to just gain that
functionality built-in...which a full six years later, never happened.
Letting perfect be the enemy of the good, at its golden finest.
Re: assert with format considered harmful
Seb wrote:
On Sunday, 26 February 2017 at 06:34:07 UTC, Ali Çehreli wrote:
So, obviously, assert message generation is not lazy. This is a WAT!
for me but perhaps there is a good reason for it.
FWIW imho we shouldn't need to write such messages at all.
It shouldn't be to difficult to lower `assert (a BINOP b)` into sth. like:
(auto ref a, auto ref b) {
if (a BINOP b) return;
onAssertFailed!"BINOP"(a, b, __FILE__, __LINE__, __FUNCTION__,
__MODULE__);
} (e1, e2);
with onAssertFailed being a nice pretty-printer in the direction of:
assert([1,2,3] == [1,2,4]); // ERROR: ([1,2,3][2] is 3) != ([1,2,4][2] is 4)
struct A { int x, y; }
auto a = A(1,2);
auto b = A(1,3);
assert(a == b); // ERROR: (a.y is 2) != (b.y is 3)
This idea is formally known as DIP83:
https://wiki.dlang.org/DIP83
or at least print the condition that failed, if there is no assert
message. this patch alone saved me alot of brain cells. somehow it is
way easier for me to look at stack trace and get "aha!" moment, than to
look at the source line with assert. even if the info is exactly the
same. ;-)
besides, assert with condition printed simply looks better.
note that your suggestion may require calling `toString()`, which may
allocate, and it may be undesirable to allocate there (maybe programmer
did't printed more detailed info exactly 'cause he wanted to avoid
possible allocations?). and condition printing done by simply adding
pretty-printed string in frontend.
Re: assert with format considered harmful
On Sunday, 26 February 2017 at 06:34:07 UTC, Ali Çehreli wrote:
So, obviously, assert message generation is not lazy. This is a
WAT! for me but perhaps there is a good reason for it.
FWIW imho we shouldn't need to write such messages at all.
It shouldn't be to difficult to lower `assert (a BINOP b)` into
sth. like:
(auto ref a, auto ref b) {
if (a BINOP b) return;
onAssertFailed!"BINOP"(a, b, __FILE__, __LINE__,
__FUNCTION__, __MODULE__);
} (e1, e2);
with onAssertFailed being a nice pretty-printer in the direction
of:
assert([1,2,3] == [1,2,4]); // ERROR: ([1,2,3][2] is 3) !=
([1,2,4][2] is 4)
struct A { int x, y; }
auto a = A(1,2);
auto b = A(1,3);
assert(a == b); // ERROR: (a.y is 2) != (b.y is 3)
This idea is formally known as DIP83:
https://wiki.dlang.org/DIP83
