WTF did happen with struct constructor and ref in 2.061 ?

js.mdnq js_adddot+mdng at gmail.com
Fri Jan 4 04:12:52 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. 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.
>
> - Jonathan M Davis


can you show an example of such a bug? I assume you mean that a 
"struct literal" ends up being a local object and a ref to it can 
easily become invalid?(in your example this is not possible 
inside main). But your example basically contradicts what you say.

There is no semantic difference between

S s = S(2); foo(s)

and

foo(S(2));

It is known as substitution theory and the second simply has an 
implicit step(which also makes it easier to program as it reduces 
an extra line).

But if the 2nd case is invalid then so is the first. i.e., What 
ever example you show as "buggy" using a "struct literal" I 
should be able to do the same without using one. (that is, 
assuming the compiler itself is not buggy in some other way)




More information about the Digitalmars-d mailing list