Is DMD 0.166 RC 1.0?
Walter Bright
newshound at digitalmars.com
Mon Sep 4 15:44:52 PDT 2006
Ivan Senji wrote:
> Is there an example where replacing
>
> f(a.prop);
>
> with
>
> auto x=a.prop; f(x); a.prop=x;
>
> would be a bad thing to do, and could result in unexpected code, or hard
> to catch bugs.
> Sure some aspects of this behavior should be well documented to avoid
> confusion (like the fact that the value is updated on function exit) but
> it is the same with most other feature.
>
> To make myself clear: D can do without this feature but without it a
> simple:
>
> write f(a.prop) -> compile&run happily
>
> is replaced with
>
> write f(a.prop) -> compile -> goto line with error -> figure out the
> error and how to fix it (might be hard the first time) ->
> select "f(a.prop)" -> Ctrl-X -> write auto x=a.prop; f(x); a.prop=x; ->
> compile&run (but less happily now)
I'd ask "why is f(x) returning a value in x?" That would normally be an
essential part of the behavior of the function, so:
f(3)
should return an error, shouldn't it? If modifying its argument is an
essential behavior of the function, and the argument is not modifiable,
probably the programmer made a mistake and the compiler should not paper
it over. And the same for every other argument that isn't an lvalue (and
so cannot be set).
If you find yourself writing:
auto x=a.prop; f(x); a.prop=x;
I would seriously question what is going on with f(). It's a big flag
that something is wrong either with f() or with the usage of f(). I
would not want the compiler papering it over.
More information about the Digitalmars-d-announce
mailing list