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