Jump to page: 1 26  
Page
Thread overview
WTF did happen with struct constructor and ref in 2.061 ?
Jan 03, 2013
deadalnix
Jan 03, 2013
Jonathan M Davis
Jan 03, 2013
deadalnix
Jan 04, 2013
Rob T
Jan 04, 2013
Rob T
Jan 04, 2013
Rob T
Jan 04, 2013
Rob T
Jan 04, 2013
Jacob Carlborg
Jan 04, 2013
Jordi Sayol
Jan 05, 2013
Jordi Sayol
Jan 05, 2013
Jordi Sayol
Jan 05, 2013
Jordi Sayol
Jan 05, 2013
Philippe Sigaud
Jan 05, 2013
Jordi Sayol
Jan 05, 2013
Philippe Sigaud
Jan 06, 2013
Philippe Sigaud
Jan 05, 2013
Rob T
Jan 06, 2013
Nick Sabalausky
Jan 06, 2013
Nick Sabalausky
Jan 06, 2013
David Nadlinger
Jan 06, 2013
Philippe Sigaud
Jan 06, 2013
Nick Sabalausky
Jan 06, 2013
Jacob Carlborg
Jan 06, 2013
Nick Sabalausky
Jan 04, 2013
Namespace
Jan 04, 2013
Jacob Carlborg
Jan 04, 2013
js.mdnq
Jan 04, 2013
Maxim Fomin
Jan 04, 2013
Jonathan M Davis
Jan 04, 2013
deadalnix
Jan 04, 2013
Ali Çehreli
Jan 04, 2013
deadalnix
Jan 05, 2013
Sönke Ludwig
Jan 06, 2013
deadalnix
Jan 05, 2013
Maxim Fomin
Jan 06, 2013
Ali Çehreli
Jan 04, 2013
js.mdnq
Jan 04, 2013
Jonathan M Davis
Jan 05, 2013
js.mdnq
Jan 05, 2013
Mehrdad
Jan 05, 2013
js.mdnq
Jan 05, 2013
Rob T
Jan 06, 2013
Jonathan M Davis
Jan 06, 2013
Ali Çehreli
Jan 06, 2013
deadalnix
January 03, 2013
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 ?
January 03, 2013
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
January 03, 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 !
January 04, 2013
On Thursday, 3 January 2013 at 23:57:19 UTC, deadalnix wrote:
>
> 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 ?
>

I have several times now pointed out in different threads that we have a *big* problem concerning the lack of a process for defining and implementing the D specification. It is very encouraging that we're now attempting to solve some big issues with the development and release process, but it only concerns the branching methods and movement of new code into a stable form. The next big ticket, which IMO is much more significant a change, is to define a process for managing the D specification in a more sensible way, in fact there is no process that I'm aware of, and if there is one it's totally dysfunctional.

At some point this problem has to be dealt with as it's a massive inhibitor for anyone to take D seriously. For example, try downloading the specification and you'll get http 404, or you get a link to some ancient crap from Amazon for .99 cents - seriously!

Try finding the most current version of the specification (there is no version to speak of). What's being proposed for the next big change? There's are DIPS, but where are they and how are they linked to the endless discussions surrounding them? Etc.

I hope this major issue gets serious attention in the new year after 2.061 is released.

--rt
January 04, 2013
On 1/3/13 7:14 PM, Rob T wrote:
> I have several times now pointed out in different threads that we have a
> *big* problem concerning the lack of a process for defining and
> implementing the D specification. It is very encouraging that we're now
> attempting to solve some big issues with the development and release
> process, but it only concerns the branching methods and movement of new
> code into a stable form. The next big ticket, which IMO is much more
> significant a change, is to define a process for managing the D
> specification in a more sensible way, in fact there is no process that
> I'm aware of, and if there is one it's totally dysfunctional.

Agreed.

> At some point this problem has to be dealt with as it's a massive
> inhibitor for anyone to take D seriously. For example, try downloading
> the specification and you'll get http 404, or you get a link to some
> ancient crap from Amazon for .99 cents - seriously!

What's the link?

> Try finding the most current version of the specification (there is no
> version to speak of). What's being proposed for the next big change?
> There's are DIPS, but where are they and how are they linked to the
> endless discussions surrounding them? Etc.

All good points.

> I hope this major issue gets serious attention in the new year after
> 2.061 is released.

This looks like written from back in time. Yes it is getting attention, I hoped at least as much is obvious by now.


Andrei


January 04, 2013
You could use 'auto ref'. It isn't offical implemented, but I use it already.
See also this thread: http://forum.dlang.org/thread/tkzyjhshbqjqxwzppdin@forum.dlang.org?page=7
January 04, 2013
On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:
>> At some point this problem has to be dealt with as it's a massive
>> inhibitor for anyone to take D seriously. For example, try downloading
>> the specification and you'll get http 404, or you get a link to some
>> ancient crap from Amazon for .99 cents - seriously!
>
> What's the link?

http://dlang.org/download.html

Look towards the bottom of page, "Documentation Downloads" "D Programming Language Specification 2.0 ebook"

Not exactly a 404 error but its the same sort of thing. The bad link should be removed until something else becomes available.

The Amazon link seems to have gone away, or I saw it somewhere else. If I come across it again, I'll be sure to let you know.

Here's the specification for sale on Amazon, it should be pulled
http://www.amazon.com/D-Programming-Language-Specification-ebook/dp/B005CCQPKK

There are other links totally unrelated to D that should be removed - it makes D look unprofessional (sorry if I offend, but it's the hard truth). In fact the whole "other" stuff should be removed from the official D website at some point soon, D needs to stand on its own IMO.

> This looks like written from back in time. Yes it is getting attention, I hoped at least as much is obvious by now.
>
>
> Andrei

Yes I see nothing but good progress happening, else I would have disappeared long ago. Thanks for putting up with my pestering :)

--rt
January 04, 2013
On 1/3/13 10:38 PM, Rob T wrote:
> Here's the specification for sale on Amazon, it should be pulled
> http://www.amazon.com/D-Programming-Language-Specification-ebook/dp/B005CCQPKK

What's wrong with the book?

Andrei
January 04, 2013
On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:
> What's the link?
>

The bad link is also here, including the Amazon link.
http://dlang.org/spec.html

The problem link and the Amazon e-book issue has been mentioned multiple times before and as recently as Nov last year.

I like the idea of the e-book but we need an up-to-date copy and it should be available free of charge. If the D community needs funding, a method of making donations is a much better and more acceptable route to take.

--rt
January 04, 2013
On 1/3/13 11:26 PM, Rob T wrote:
> On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:
>> What's the link?
>>
>
> The bad link is also here, including the Amazon link.
> http://dlang.org/spec.html
>
> The problem link and the Amazon e-book issue has been mentioned multiple
> times before and as recently as Nov last year.

I don't understand what the "issue" is.

> I like the idea of the e-book but we need an up-to-date copy and it
> should be available free of charge. If the D community needs funding, a
> method of making donations is a much better and more acceptable route to
> take.

This is a misunderstanding and I confess I'm mildly miffed by it. The e-book is generated from the online documentation. $0.99 is the smallest price Amazon would allow any self-publication to be on their site. Some people (negligible as a source of income, but not few; the book makes it at times on top 100 bestseller list in its category) do find value in having the content on their Kindle, and are willing to pay one dollar for it, so there is value in having it there. To construe that as an awkward attempt to make money is quite a bit of a stretch.


Andrei
« First   ‹ Prev
1 2 3 4 5 6