WTF did happen with struct constructor and ref in 2.061 ?

deadalnix deadalnix at gmail.com
Thu Jan 3 15:57:17 PST 2013


On Thursday, 3 January 2013 at 23:40:39 UTC, Jonathan M Davis 
wrote:
> On Friday, January 04, 2013 00:20:58 deadalnix wrote:
>> I find myself with massive breakage in my codebase. I have a 
>> lot
>> of code doing stuff like foo(Bar(args)) where foo expect a ref
>> parameter. This used to work just fine, but now it do not.
>> 
>> This seems to me particularly dubious as the compiler 
>> introduce a
>> temporary to call the constructor on. Bar(args) HAVE an 
>> address.
>> 
>> Looking at the change log, I can't find anything relevant to 
>> the
>> subject. What the fuck did happen and why ?
>
> http://d.puremagic.com/issues/show_bug.cgi?id=9069
>
> It makes _no_ sense for struct literals to be treated as 
> lvalues. They're
> temporaries, not variables. This has been discussed a number of 
> times before
> and was finally fixed with 2.061.

This has been discussed, but I'm pretty sure nothing was really 
conclusive (especially when I read about auto ref).

And even if it was, how come that this isn't advertised with some 
big red sign ? If a person that read the newsgroup like me didn't 
see that coming, what about any regular D user ?

> Previously, you got nonsensical behavior like
>
> struct S
> {
>  int i;
> }
>
> S foo(ref S s)
> {
>  return s;
> }
>
> S bar(int i)
> {
>  return S(i);
> }
>
> void main()
> {
>  S s = S(2);
>  foo(s); //compiles as it should
>  foo(S(5)); //compiles when it shouldn't
>  foo(bar(5)); //fails to compile as it should
> }
>
> There should be no difference between a struct literal and a 
> struct returned by
> value from a function. Code which depended on struct literals 
> being lvalues was
> depending on buggy behavior.
>

But the struct storage is passed to the constructor ! It has an 
actual storage !


More information about the Digitalmars-d mailing list