assert(object) fails to adhere to the principle of least surprise
If I do
if (object) {
...
}
What happens is fairly obvious, and is equivalent to
if (object !is null) {
}
However, if I do
auto object = new Object();
assert(object);
What I expect to happen is
assert(object !is null);
Just as in the above example. What happens however is the program seg
faults. Why? Because it turns out what DMD turns it (silently) into is
object.checkInvariants(); // Whatever it's called.
This is bad enough, however it gets pants-on-head stupid as *object is
not checked for null*. I think the silent rewrite is bad design, but not
checking for null is so stupid, so obvious to anyone who actually uses
the language, I can't believe it's existed for so long. The fact that
assert(object);
and
import std.exception;
enforce(object);
do different things boggles my mind. One must write
assert(object !is null);
or
assert(!!object);
and every day it's like a giant stabbing pain. A stupid wrong headed
design that makes my experience with D _worse_. Just expose a method for
checking the invariant explicitly, and don't do this silent rewrite
bullshit. Any chance of getting a change of behaviour?
FWIW, GDC doesn't do the rewrite, and SDC (the compiler I'm working on
github.com/bhelyer/sdc) won't either.
Re: assert(object) fails to adhere to the principle of least surprise
A few corrections. On Sat, 29 Jan 2011 12:02:57 +, Bernard Helyer wrote: > auto object = new Object(); > assert(object); This segfaults if object is null, which is obviously impossible in this example. > > FWIW, GDC doesn't do the rewrite, On structs, it does the rewrite on class instances (boo!).
Re: assert(object) fails to adhere to the principle of least surprise
Further correction. On Sat, 29 Jan 2011 12:09:41 +, Bernard Helyer wrote: >> FWIW, GDC doesn't do the rewrite, > > On structs, it does the rewrite on class instances (boo!). It checks for null then checks the invariant. I think that's a good compromise, given that an object without an invariant passes the assert.
Re: assert(object) fails to adhere to the principle of least surprise
Bernard Helyer napisał:
> If I do
>
> if (object) {
> ...
> }
>
> What happens is fairly obvious, and is equivalent to
>
> if (object !is null) {
> }
>
> However, if I do
>
> auto object = new Object();
> assert(object);
>
> What I expect to happen is
>
> assert(object !is null);
>
> Just as in the above example. What happens however is the program seg
> faults. Why? Because it turns out what DMD turns it (silently) into is
>
> object.checkInvariants(); // Whatever it's called.
>
> This is bad enough, however it gets pants-on-head stupid as *object is
> not checked for null*. I think the silent rewrite is bad design, but not
> checking for null is so stupid, so obvious to anyone who actually uses
> the language, I can't believe it's existed for so long. The fact that
>
> assert(object);
>
> and
>
> import std.exception;
> enforce(object);
>
> do different things boggles my mind. One must write
>
>assert(object !is null);
>
> or
>
>assert(!!object);
>
> and every day it's like a giant stabbing pain. A stupid wrong headed
> design that makes my experience with D _worse_. Just expose a method for
> checking the invariant explicitly, and don't do this silent rewrite
> bullshit. Any chance of getting a change of behaviour?
>
> FWIW, GDC doesn't do the rewrite, and SDC (the compiler I'm working on
> github.com/bhelyer/sdc) won't either.
http://d.puremagic.com/issues/show_bug.cgi?id=796
Vote up ;)
--
Tomek
Re: assert(object) fails to adhere to the principle of least surprise
On 1/29/11, Tomek Sowiński wrote: > http://d.puremagic.com/issues/show_bug.cgi?id=796 > > Vote up ;) > Wow, that is an old-school bug (2007!). :p I wonder which bug report is the oldest one that is still opened.
Re: assert(object) fails to adhere to the principle of least surprise
Andrej Mitrovic wrote: On 1/29/11, Tomek Sowiński wrote: http://d.puremagic.com/issues/show_bug.cgi?id=796 Vote up ;) Wow, that is an old-school bug (2007!). :p I wonder which bug report is the oldest one that is still opened. That would be #107: Wrong filename in error message when using a mixin http://d.puremagic.com/issues/show_bug.cgi?id=107 -- Simen
