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