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)
