www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - WTF did happen with struct constructor and ref in 2.061 ?

reply "deadalnix" <deadalnix gmail.com> writes:
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 ?
Jan 03 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Jan 03 2013
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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 !
Jan 03 2013
next sibling parent reply "Rob T" <rob ucora.com> writes:
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
Jan 03 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 03 2013
next sibling parent reply "Rob T" <rob ucora.com> writes:
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
Jan 03 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 03 2013
prev sibling parent reply "Rob T" <rob ucora.com> writes:
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
Jan 03 2013
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 03 2013
next sibling parent "Rob T" <rob ucora.com> writes:
On Friday, 4 January 2013 at 04:32:46 UTC, Andrei Alexandrescu 
wrote:

 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


Sorry, I didn't want to offend and I honestly never thought 
anyone was making money from it, I just never understood why it 
was on Amazon yet not on this website, so thanks for taking the 
time to explain why the e-book is on Amazon, it makes perfect 
sense now.

Perhaps an explanation such as "For your convenience, an e-book 
is available at Amazon ..." next to the fixed link is a good 
solution to prevent any possible misunderstandings.

No matter, I really do not want to get into this level of detail 
as it's of very limited significance right now. All I was 
attempting to point out was the need to move on with formalizing 
a process for managing the specification, and you've clearly 
acknowledged the desire to do exactly that. Once we have a better 
process in place, many old recurring problems will automatically 
go away.

--rt
Jan 03 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-04 05:32, Andrei Alexandrescu wrote:

 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.


There's a link on the top of that page, "Mobi ebook", which links to 
this page

http://www.digitalmars.com/d/2.0/dlangspec.mobi

That page results in a 404 page.

-- 
/Jacob Carlborg
Jan 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/4/13 6:11 AM, Jacob Carlborg wrote:

 On 2013-01-04 05:32, Andrei Alexandrescu wrote:

 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.


 There's a link on the top of that page, "Mobi ebook", which links to
 this page

 http://www.digitalmars.com/d/2.0/dlangspec.mobi

 That page results in a 404 page.


Got it, thanks. Will fwd to Walter.

Andrei
Jan 04 2013
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
Al 04/01/13 18:17, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 6:11 AM, Jacob Carlborg wrote:

 On 2013-01-04 05:32, Andrei Alexandrescu wrote:

 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.


 There's a link on the top of that page, "Mobi ebook", which links to
 this page

 http://www.digitalmars.com/d/2.0/dlangspec.mobi

 That page results in a 404 page.


 
 Got it, thanks. Will fwd to Walter.
 
 Andrei
 


dlangspec.mobi is back! :-)

-- 
Jordi Sayol
Jan 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/4/13 5:44 PM, Jordi Sayol wrote:

 dlangspec.mobi is back! :-)


Did my best to fix it. All, please take a look.

Andrei
Jan 04 2013
next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 5:44 PM, Jordi Sayol wrote:

 dlangspec.mobi is back! :-)


 
 Did my best to fix it. All, please take a look.
 
 Andrei
 


I found these things:

Data Type Compatibility
http://img.ly/rwtF

Named Character Entities
http://img.ly/rwug

Structs & Unions
http://img.ly/rwum

Trait
http://img.ly/rwup


May only happen in my viewer (calibre for Linux).

Regards,
-- 
Jordi Sayol
Jan 04 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/4/13 6:59 PM, Jordi Sayol wrote:

 Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 5:44 PM, Jordi Sayol wrote:

 dlangspec.mobi is back! :-)


 Did my best to fix it. All, please take a look.

 Andrei


 I found these things:

 Data Type Compatibility
 http://img.ly/rwtF

 Named Character Entities
 http://img.ly/rwug

 Structs&  Unions
 http://img.ly/rwum

 Trait
 http://img.ly/rwup


 May only happen in my viewer (calibre for Linux).


Thanks a bunch! I made one more pass and fixed the excessively large 
left and right margins. Then I took a look at each of the issues above 
with Kindle viewer on OSX, they all work for me.

All - one more look please: http://dlang.org/dlangspec.mobi


Thanks,

Andrei
Jan 04 2013
next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
Al 05/01/13 03:05, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 6:59 PM, Jordi Sayol wrote:

 Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 5:44 PM, Jordi Sayol wrote:

 dlangspec.mobi is back! :-)


 Did my best to fix it. All, please take a look.

 Andrei


 I found these things:

 Data Type Compatibility
 http://img.ly/rwtF

 Named Character Entities
 http://img.ly/rwug

 Structs&  Unions
 http://img.ly/rwum

 Trait
 http://img.ly/rwup


 May only happen in my viewer (calibre for Linux).


 
 Thanks a bunch! I made one more pass and fixed the excessively large left and
right margins. Then I took a look at each of the issues above with Kindle
viewer on OSX, they all work for me.
 
 All - one more look please: http://dlang.org/dlangspec.mobi
 
 
 Thanks,


Great work! All these things properly shown on Calibre too.

Just one more thing. At the "Table of Contents", there are two disabled links,
"Introduction" and "Inline Assembler":

http://ves.cat/b-Vh

Regards,
-- 
Jordi Sayol
Jan 04 2013
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
Al 05/01/13 03:42, En/na Jordi Sayol ha escrit:

 Al 05/01/13 03:05, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 6:59 PM, Jordi Sayol wrote:

 Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:

 On 1/4/13 5:44 PM, Jordi Sayol wrote:

 dlangspec.mobi is back! :-)


 Did my best to fix it. All, please take a look.

 Andrei


 I found these things:

 Data Type Compatibility
 http://img.ly/rwtF

 Named Character Entities
 http://img.ly/rwug

 Structs&  Unions
 http://img.ly/rwum

 Trait
 http://img.ly/rwup


 May only happen in my viewer (calibre for Linux).


 Thanks a bunch! I made one more pass and fixed the excessively large left and
right margins. Then I took a look at each of the issues above with Kindle
viewer on OSX, they all work for me.

 All - one more look please: http://dlang.org/dlangspec.mobi


 Thanks,


 
 Great work! All these things properly shown on Calibre too.
 
 Just one more thing. At the "Table of Contents", there are two disabled links,
"Introduction" and "Inline Assembler":
 
 http://ves.cat/b-Vh
 


In "Table of contents", last chapter "Vector Extensions" is missing.

-- 
Jordi Sayol
Jan 04 2013
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sat, Jan 5, 2013 at 3:05 AM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 All - one more look please:
http://dlang.org/dlangspec.**mobi<http://dlang.org/dlangspec.mobi>



 Calibre does not open it here (Linux, KDE) not does it accept to convert
it.
Jan 05 2013
prev sibling next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
Al 05/01/13 10:10, En/na Philippe Sigaud ha escrit:

 
  Calibre does not open it here (Linux, KDE) not does it accept to convert it.
 


No problem open the last http://dlang.org/dlangspec.mobi (built by andralex)
with Calibre v0.8.38 (Linux 64-bit, Mate)

-- 
Jordi Sayol
Jan 05 2013
prev sibling parent reply Philippe Sigaud <philippe.sigaud gmail.com> writes:
On Sat, Jan 5, 2013 at 9:17 PM, Jordi Sayol <g.sayol yahoo.es> wrote:


 Al 05/01/13 10:10, En/na Philippe Sigaud ha escrit:

  Calibre does not open it here (Linux, KDE) not does it accept to


 convert it.


 No problem open the last http://dlang.org/dlangspec.mobi (built by
 andralex) with Calibre v0.8.38 (Linux 64-bit, Mate)


Calibre 0.8.64 here. Still does not work.
(...)
I updated to 0.9.13 (latest version) and it works, yeah!

Andrei, would that be possible to give us access to the .css that gives the
mobi file its global appearance? I'd like D-related mobi/epub that I create
to have the same look-and-feel.



 Jan 05 2013



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/5/13 5:22 PM, Philippe Sigaud wrote:

 Andrei, would that be possible to give us access to the .css that gives
 the mobi file its global appearance? I'd like D-related mobi/epub that I
 create to have the same look-and-feel.


https://github.com/D-Programming-Language/d-programming-language.org/blob/master/ebook.css

https://github.com/D-Programming-Language/d-programming-language.org/blob/master/ebook.ddoc

See also the makefile.


Andrei



 Jan 05 2013



  parent  Philippe Sigaud <philippe.sigaud gmail.com>  writes:


  Andrei, would that be possible to give us access to the .css that gives

 the mobi file its global appearance? I'd like D-related mobi/epub that I
 create to have the same look-and-feel.


 https://github.com/D-**Programming-Language/d-**
 programming-language.org/blob/**master/ebook.css<https://github.com/D-Programming-Language/d-programming-language.org/blob/master/ebook.css>

 https://github.com/D-**Programming-Language/d-**
 programming-language.org/blob/**master/ebook.ddoc<https://github.com/D-Programming-Language/d-programming-language.org/blob/master/ebook.ddoc>

 See also the makefile.



Thanks a lot.



 Jan 06 2013



prev sibling  parent  "Rob T" <rob ucora.com>  writes:


On Friday, 4 January 2013 at 23:03:32 UTC, Andrei Alexandrescu 
wrote:

 On 1/4/13 5:44 PM, Jordi Sayol wrote:

 dlangspec.mobi is back! :-)


 Did my best to fix it. All, please take a look.

 Andrei


Thanks Andrei!

Calibre on Linux gives me errors when I try to view.

FBReader opens it OK, but the tables are not formatted correctly 
and show up flat.

I have not tried on an actual tablet or reader device.

A suggestion is to file it as a bug against the website or 
documentation and remove the link or note that there may be 
problems with it until a fix is ready.

--rt



 Jan 04 2013



prev sibling  parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On Thu, 03 Jan 2013 23:32:45 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/3/13 11:26 PM, Rob T wrote:
 

 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.


It's an ebook version of the content on dlang.org, right? That should
be free. If Amazon won't allow it to be free then it shouldn't be on
Amazon. End of story.

If you want people to be able to read it on a Kindle, then use
something that doesn't require going through Amazon. If it's not
possible to provide a document that's free to view on Kindle (I don't
know whether that's the case), then it's the users own damn problem
for buying a device that won't allow them to view free/freely-available
content. But the bottom line is, we should not, and should never have
released an electronic copy of the website content in a for-cost form.
I was opposed to to it from the beginning.


 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.
 


It's not about whether anyone's trying to make money. It's about the
ethics *AND THE PUBLIC IMAGE* of selling copies of our own
free-on-the-web documentation. One dollar, one cent, half a cent, it's
irrelevent.

If a platform or website won't allow free content to be free, then said
content doesn't belong on that platform/website, period. That's all
there is to it.



 Jan 05 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/6/13 12:01 AM, Nick Sabalausky wrote:

 On Thu, 03 Jan 2013 23:32:45 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 On 1/3/13 11:26 PM, Rob T wrote:


 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.


 It's an ebook version of the content on dlang.org, right? That should
 be free. If Amazon won't allow it to be free then it shouldn't be on
 Amazon. End of story.


Walter and I discussed this matter for a while and reached a different 
conclusion. Amazon has good distribution which we found worthwhile. The 
content is the same as the one freely available on the website, and 
we're not sketchy about it. The material can be read on the Kindle 
regardless of provenance.

Andrei



 Jan 05 2013



  parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On Sun, 06 Jan 2013 00:45:24 -0500
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 On 1/6/13 12:01 AM, Nick Sabalausky wrote:

 On Thu, 03 Jan 2013 23:32:45 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 On 1/3/13 11:26 PM, Rob T wrote:


 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.


 It's an ebook version of the content on dlang.org, right? That
 should be free. If Amazon won't allow it to be free then it
 shouldn't be on Amazon. End of story.


 
 Walter and I discussed this matter for a while and reached a
 different conclusion. Amazon has good distribution which we found
 worthwhile.


Amazon's reach is irrelevant given the bigger issue.


 The content is the same as the one freely available on
 the website,


Which is exactly why it has no business existing in a paid
electronic form.


 and we're not sketchy about it.


I'm tempted argue that it's _inherently_ sketchy, HOWEVER that's
irrelevant anyway as, sketchy or not, it still creates an appearance of
impropriety, which is bad enough for us.



 Jan 05 2013



 next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/6/13 12:58 AM, Nick Sabalausky wrote:

 On Sun, 06 Jan 2013 00:45:24 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 On 1/6/13 12:01 AM, Nick Sabalausky wrote:

 On Thu, 03 Jan 2013 23:32:45 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>   wrote:


 On 1/3/13 11:26 PM, Rob T wrote:


 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.


 It's an ebook version of the content on dlang.org, right? That
 should be free. If Amazon won't allow it to be free then it
 shouldn't be on Amazon. End of story.


 Walter and I discussed this matter for a while and reached a
 different conclusion. Amazon has good distribution which we found
 worthwhile.


 Amazon's reach is irrelevant given the bigger issue.


 The content is the same as the one freely available on
 the website,


 Which is exactly why it has no business existing in a paid
 electronic form.


 and we're not sketchy about it.


 I'm tempted argue that it's _inherently_ sketchy, HOWEVER that's
 irrelevant anyway as, sketchy or not, it still creates an appearance of
 impropriety, which is bad enough for us.


That's not my perception at all, which signals we might have reached 
irreducible positions. I won't discuss this further.

Andrei



 Jan 05 2013



  parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Sunday, 6 January 2013 at 06:06:21 UTC, Andrei Alexandrescu 
wrote:

 I won't discuss this further.


Too bad. It seems that the whole discussion could be resolved by 
just providing an explanatory comment along the lines of »This 
specification can also be accessed in other formats at dlang.org« 
in the Amazon product description.

David



 Jan 06 2013



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/6/13 11:52 AM, David Nadlinger wrote:

 On Sunday, 6 January 2013 at 06:06:21 UTC, Andrei Alexandrescu wrote:

 I won't discuss this further.


 Too bad. It seems that the whole discussion could be resolved by just
 providing an explanatory comment along the lines of »This specification
 can also be accessed in other formats at dlang.org« in the Amazon
 product description.


I think that's a great idea, will do.

Andrei



 Jan 06 2013



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/6/13 2:39 PM, Andrei Alexandrescu wrote:

 On 1/6/13 11:52 AM, David Nadlinger wrote:

 On Sunday, 6 January 2013 at 06:06:21 UTC, Andrei Alexandrescu wrote:

 I won't discuss this further.


 Too bad. It seems that the whole discussion could be resolved by just
 providing an explanatory comment along the lines of »This specification
 can also be accessed in other formats at dlang.org« in the Amazon
 product description.


 I think that's a great idea, will do.

 Andrei


Submitted this review:

Official D language specification formatted for the Kindle

We are producing this from the same source files as the online 
specification to be found at http://dlang.org. The .mobi file is also 
freely downloadable from http://dlang.org/dlangspec.mobi. Please let the 
author know of any rendering issues. For discussions related to the 
design of the D programming language, tune to http://forum.dlang.org. Enjoy!


Andrei



 Jan 06 2013



  parent reply Philippe Sigaud <philippe.sigaud gmail.com>  writes:


On Sun, Jan 6, 2013 at 8:49 PM, Andrei Alexandrescu <
SeeWebsiteForEmail erdani.org> wrote:


 Submitted this review:


 Official D language specification formatted for the Kindle

 We are producing this from the same source files as the online
 specification to be found at http://dlang.org. The .mobi file is also
 freely downloadable from
http://dlang.org/dlangspec.**mobi<http://dlang.org/dlangspec.mobi>.
 Please let the author know of any rendering issues. For discussions related
 to the design of the D programming language, tune to
 http://forum.dlang.org. Enjoy!

 That is quite good. Clear, to the point and full of links.


Could you explain somewhere how the .mobi is generated? (Not in the review,
of course, but on the newsgroup)



 Jan 06 2013



  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


On 1/6/13 2:57 PM, Philippe Sigaud wrote:

 On Sun, Jan 6, 2013 at 8:49 PM, Andrei Alexandrescu
 <SeeWebsiteForEmail erdani.org <mailto:SeeWebsiteForEmail erdani.org>>
 wrote:


     Submitted this review:

     Official D language specification formatted for the Kindle

     We are producing this from the same source files as the online
     specification to be found at http://dlang.org. The .mobi file is
     also freely downloadable from http://dlang.org/dlangspec.__mobi
     <http://dlang.org/dlangspec.mobi>. Please let the author know of any
     rendering issues. For discussions related to the design of the D
     programming language, tune to http://forum.dlang.org. Enjoy!

 That is quite good. Clear, to the point and full of links.


Unfortunately they removed the links.


 Could you explain somewhere how the .mobi is generated? (Not in the
 review, of course, but on the newsgroup)


It's all in posix.mak on github.


Andrei



 Jan 06 2013



prev sibling  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On Sun, 6 Jan 2013 00:58:11 -0500
Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> wrote:


 On Sun, 06 Jan 2013 00:45:24 -0500
 Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:
 

 On 1/6/13 12:01 AM, Nick Sabalausky wrote:

 On Thu, 03 Jan 2013 23:32:45 -0500
 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org>  wrote:


 On 1/3/13 11:26 PM, Rob T wrote:


 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.


 It's an ebook version of the content on dlang.org, right? That
 should be free. If Amazon won't allow it to be free then it
 shouldn't be on Amazon. End of story.


 
 Walter and I discussed this matter for a while and reached a
 different conclusion. Amazon has good distribution which we found
 worthwhile.


 
 Amazon's reach is irrelevant given the bigger issue.
 

 The content is the same as the one freely available on
 the website,


 
 Which is exactly why it has no business existing in a paid
 electronic form.
 

 and we're not sketchy about it.


 
 I'm tempted argue that it's _inherently_ sketchy, HOWEVER that's
 irrelevant anyway as, sketchy or not, it still creates an appearance
 of impropriety, which is bad enough for us.
 


I'll put it another way: We've had public perception troubles in the
past. D1's competing std libs. Claims of not being OSS. We should know
by now not to do things that invite the wrong public perception.

Last thing we need is for a bunch of slashdotters or some such to notice
"Hey, wait a minute, these D guys are trying to sell copies of their own
website! WTF?!" If that got started, do you really think they're
going to stick around long enough to listen to our explanation of "Why
it's not as bad as it looks"?

Someone wants to read a website/pdf/ebook/whatever of the site on their
Kindle, then fine, we can provide our *free* copies and then people can
do as they please with them. Problem solved, there's nothing left to
argue.

(FWIW, a printed/bound hardcopy would be a different matter as there are
printing and material costs involved. But I'm not saying that would be a
good idea for something like this which needs to stay up-to-date,
of course.)



 Jan 05 2013



prev sibling  parent reply Jacob Carlborg <doob me.com>  writes:


On 2013-01-06 06:01, Nick Sabalausky wrote:


 It's an ebook version of the content on dlang.org, right? That should
 be free. If Amazon won't allow it to be free then it shouldn't be on
 Amazon. End of story.

 If you want people to be able to read it on a Kindle, then use
 something that doesn't require going through Amazon. If it's not
 possible to provide a document that's free to view on Kindle (I don't
 know whether that's the case), then it's the users own damn problem
 for buying a device that won't allow them to view free/freely-available
 content.


It's possible to read arbitrary PDF files on a Kindle.

-- 
/Jacob Carlborg



 Jan 06 2013



  parent  Nick Sabalausky <SeeWebsiteToContactMe semitwist.com>  writes:


On Sun, 06 Jan 2013 12:44:13 +0100
Jacob Carlborg <doob me.com> wrote:


 On 2013-01-06 06:01, Nick Sabalausky wrote:
 

 It's an ebook version of the content on dlang.org, right? That
 should be free. If Amazon won't allow it to be free then it
 shouldn't be on Amazon. End of story.

 If you want people to be able to read it on a Kindle, then use
 something that doesn't require going through Amazon. If it's not
 possible to provide a document that's free to view on Kindle (I
 don't know whether that's the case), then it's the users own damn
 problem for buying a device that won't allow them to view
 free/freely-available content.


 
 It's possible to read arbitrary PDF files on a Kindle.
 


Good, then there really is no need for the paid version on Amazon.



 Jan 06 2013



prev sibling  parent  Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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


I've added the .mobi build to the regular site build. Unfortunately, I'm 
getting warnings and an output with artifacts:

http://dlang.org/dlangspec.mobi

Will look into it.


Andrei



 Jan 04 2013



prev sibling next sibling parent  "Namespace" <rswhite4 googlemail.com>  writes:


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



 Jan 03 2013



prev sibling  parent  Jacob Carlborg <doob me.com>  writes:


On 2013-01-04 00:57, 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 had the same problem. Thank god I saw this thread.

-- 
/Jacob Carlborg



 Jan 04 2013



prev sibling  parent reply "js.mdnq" <js_adddot+mdng gmail.com>  writes:


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)



 Jan 04 2013



 next sibling parent  "Maxim Fomin" <maxim maxim-fomin.ru>  writes:


On Friday, 4 January 2013 at 12:12:53 UTC, js.mdnq wrote:

 There is no semantic difference between

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

 and

 foo(S(2));


In the first case dtor (if any) is called at the end of the 
scope, in the second after expression being evaluated. It also 
may influence optimization.

Consider this:

import std.stdio;

struct S { ~this() { writeln("dtor"); } }

void foo(ref S s)
{
	writeln("ref");
}

void foo(S s)
{
	writeln("non-ref");
}

void one()
{
	S s;
	foo(s);
	writeln("end");
}

void two()
{
	foo(S());
	writeln("end");
}

void main()
{
	one();
	two();
}

Output is:

ref
end
dtor
ref
dtor
end

If dmd supports struct lvalues by creating a temporary, then this 
temporary would be passed by reference, be modified and 
immidiately thrown away (although it depends on what dmd actually 
did - I have the latest version now and cannot check old 
behavior). This can lead to bugs caused by changing structs and 
not saving their state.



 Jan 04 2013



prev sibling  parent reply Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Friday, January 04, 2013 13:12:52 js.mdnq wrote:

 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));


There's a _huge_ difference between those two. In the first case, you have a 
variable which exists beyond the end of the function call. In the second, you 
have temporary which is destroyed as soon as the statement has completed. 
Where there's no real difference is

foo(S(2));
foo(funcThatReturnsS());

and yet previously, if foo accepted its argument by ref, the first compiled and 
the second didn't. In both cases, you're dealing with a temporary. They 
shouldn't be treated any differently from one another, and as both are 
temporaries, both should be treated as rvalues.

Also, it's completely nonsensical for a function which is supposed to be 
taking its argument by ref to take temporaries. A function takes its argument 
by ref so that it can mutate it, and if it accepts rvalues, then you lose the 
changes, because you're not dealing with a variable that lasts beyond the 
statement that the function call is in.

If the issue is that someone wants the function to avoid making copies of the 
argument if it's not necessary, then that's what auto ref is for (and why the 
discussion how to implement that for non-templated functions is so important), 
and anyone who wants that is going to want it for foo(funcThatReturnsS()) just 
as much as they want it for foo(S(2)), making it so that ref doesn't solve 
their problem anyway (not to mention, in both of those cases, the ref is 
completely unnecessary, because if the function doesn't use ref, a move should 
be done rather than a copy, meaning that having foo(S(2)) work where foo 
accepts by ref doesn't save you from any copies anyway).

The fact that struct literals have been treated as lvalues is just plain 
buggy. There should be _zero_ difference between how a struct literal is 
treated and how the return value of a function is treated. Both are 
temporaries and should be treated as such.

- Jonathan M Davis



 Jan 04 2013



 next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote:

 On Friday, January 04, 2013 13:12:52 js.mdnq wrote:

 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));


 There's a _huge_ difference between those two. In the first 
 case, you have a
 variable which exists beyond the end of the function call. In 
 the second, you
 have temporary which is destroyed as soon as the statement has 
 completed.
 Where there's no real difference is

 foo(S(2));
 foo(funcThatReturnsS());


This may not have a storage :
foo(funcThatReturnsS());

This MUST have a storage (as this storage is passed to the ctor) :
foo(S(2));

So it is in fact different.


 Also, it's completely nonsensical for a function which is 
 supposed to be
 taking its argument by ref to take temporaries. A function 
 takes its argument
 by ref so that it can mutate it, and if it accepts rvalues, 
 then you lose the
 changes, because you're not dealing with a variable that lasts 
 beyond the
 statement that the function call is in.


A function can take ref argument for performance reasons. A 
function caller may not care about reading the changes.

Yes, if it for performance, auto ref should be used, but why in 
the first place a breaking change have been made BEFORE auto ref 
is sorted out ? Now it is like saying this is incorrect, here is 
the correct way. Ha, BTW, the correct way isn't implemented yet 
so we did break your code in unfixable way.


 If the issue is that someone wants the function to avoid making 
 copies of the
 argument if it's not necessary, then that's what auto ref is 
 for (and why the
 discussion how to implement that for non-templated functions is 
 so important),
 and anyone who wants that is going to want it for 
 foo(funcThatReturnsS()) just
 as much as they want it for foo(S(2)), making it so that ref 
 doesn't solve
 their problem anyway (not to mention, in both of those cases, 
 the ref is
 completely unnecessary, because if the function doesn't use 
 ref, a move should
 be done rather than a copy, meaning that having foo(S(2)) work 
 where foo
 accepts by ref doesn't save you from any copies anyway).

 The fact that struct literals have been treated as lvalues is 
 just plain
 buggy.


struct Bar {
	uint i;

	this(uint foo) {
		import std.stdio;
		writeln(&this);
	}
}

void main() {
	Bar(0);
}


 There should be _zero_ difference between how a struct literal 
 is
 treated and how the return value of a function is treated. Both 
 are
 temporaries and should be treated as such.


Code above show there is.

 - Jonathan M Davis





 Jan 04 2013



  parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com>  writes:


On 01/04/2013 10:48 AM, deadalnix wrote:

 On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote:



 There is no semantic difference between

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

 and

 foo(S(2));


 There's a _huge_ difference between those two. In the first case, you
 have a
 variable which exists beyond the end of the function call. In the
 second, you
 have temporary which is destroyed as soon as the statement has 




completed.

Still, there is no semantic difference. I know this issue from C++. At 
first I had embraced it but I am not so sure anymore. The language is 
getting out of its way to protect the programmer. A language like C++ 
that gives so much freedom to do many other unsafe things...

Constructors and functions do not affect objects alone. However frowned 
upon, a function that is called on an S may have side-effects that are 
beyond the object itself. If foo() does s.bar() and S.bar has a 
side-effect, I wouldn't care about the changes on the rvalue object itself.

So, I think C++ could have allowed binding rvalues to references to 
non-const. I don't think I would be bothered with that. If I had fooled 
myself occasionally, so be it.


 Where there's no real difference is

 foo(S(2));
 foo(funcThatReturnsS());




Agreed.



 This may not have a storage :
 foo(funcThatReturnsS());


I don't see that. funcThatReturnsS returns an S, which must have a 
storage as well.


 This MUST have a storage (as this storage is passed to the ctor) :
 foo(S(2));

 So it is in fact different.


 Also, it's completely nonsensical for a function which is supposed to be
 taking its argument by ref to take temporaries. A function takes its
 argument
 by ref so that it can mutate it, and if it accepts rvalues, then you
 lose the
 changes, because you're not dealing with a variable that lasts 




beyond the

 statement that the function call is in.




Getting back to this issue: So what? I have one more bug in my code.


 A function can take ref argument for performance reasons. A function
 caller may not care about reading the changes.

 Yes, if it for performance, auto ref should be used, but why in the
 first place a breaking change have been made BEFORE auto ref is sorted
 out ?


I agree with all of that. (Although, the French grammar rule of that 
space before the question mark is hurting my eyes! :p)


 If the issue is that someone wants the function to avoid making copies
 of the
 argument if it's not necessary, then that's what auto ref is for (and
 why the
 discussion how to implement that for non-templated functions is so
 important),




I hope D's 'auto ref' solution solves this issue once and for all. :)


 struct Bar {
 uint i;

 this(uint foo) {
 import std.stdio;
 writeln(&this);
 }
 }

 void main() {
 Bar(0);
 }


 There should be _zero_ difference between how a struct literal is
 treated and how the return value of a function is treated. Both are
 temporaries and should be treated as such.


 Code above show there is.


I don't see that. There is storage for the rvalue returned from 
funcThatReturnsBar() as well, no?

struct Bar {
     uint i;

     this(uint foo) {
         import std.stdio;
         writeln(&this);
     }
}

void foo(Bar bar)
{}

Bar funcThatReturnsBar()
{
     return Bar(1);
}

void main() {
     foo(Bar(0));
     foo(funcThatReturnsBar());
}

That program prints two addresses for me:

7FFFF1076290
7FFFF1076298

Ali



 Jan 04 2013



 next sibling parent reply "deadalnix" <deadalnix gmail.com>  writes:


On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:

 This may not have a storage :
 foo(funcThatReturnsS());


 I don't see that. funcThatReturnsS returns an S, which must 
 have a storage as well.


This is where things are subtle. Depending on the calling 
convention, the struct may be returned into a register. In such 
case it has no storage in memory.


 I agree with all of that. (Although, the French grammar rule of 
 that space before the question mark is hurting my eyes! :p)


In fact, this is even worse, french grammar specify that this 
should be a non-breaking space :D


 Code above show there is.


 I don't see that. There is storage for the rvalue returned from 
 funcThatReturnsBar() as well, no?

 struct Bar {
     uint i;

     this(uint foo) {
         import std.stdio;
         writeln(&this);
     }
 }

 void foo(Bar bar)
 {}

 Bar funcThatReturnsBar()
 {
     return Bar(1);
 }

 void main() {
     foo(Bar(0));
     foo(funcThatReturnsBar());
 }

 That program prints two addresses for me:

 7FFFF1076290
 7FFFF1076298

 Ali


You have to understand that Bar(1) within funcThatReturnsBar have 
a storage, but it is then moved when returned. It can be moved to 
a register for instance, so I can't take a reference.

In the example terms, 7FFFF1076298 is the location on stack of 
Bar(1). But this location don't exist anymore when you return. On 
x86, The value will be in EAX in this particular example, so it 
effectively cannot be referenced.



 Jan 04 2013



  parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig outerproduct.org>  writes:


Am 04.01.2013 20:35, schrieb deadalnix:

 On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:

 This may not have a storage :
 foo(funcThatReturnsS());


 I don't see that. funcThatReturnsS returns an S, which must have a storage as
well.


 
 This is where things are subtle. Depending on the calling convention, the
struct may be returned
 into a register. In such case it has no storage in memory.
 


Although, nothing stops the compiler from initializing a struct in a register
either. At least when
the constructor can be inlined.



 Jan 05 2013



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Saturday, 5 January 2013 at 21:23:20 UTC, Sönke Ludwig wrote:

 Am 04.01.2013 20:35, schrieb deadalnix:

 On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:

 This may not have a storage :
 foo(funcThatReturnsS());


 I don't see that. funcThatReturnsS returns an S, which must 
 have a storage as well.


 
 This is where things are subtle. Depending on the calling 
 convention, the struct may be returned
 into a register. In such case it has no storage in memory.
 


 Although, nothing stops the compiler from initializing a struct 
 in a register either. At least when
 the constructor can be inlined.


In this case, this is a register promotion that happen as an 
optimization. This can happen to ANY variable, so I don't see how 
it is particularly relevant here. The important thing is that the 
struct HAVE a storage, and may be promoted in register as an 
optimization.



 Jan 06 2013



prev sibling  parent reply "Maxim Fomin" <maxim maxim-fomin.ru>  writes:


On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:

 On 01/04/2013 10:48 AM, deadalnix wrote:

 On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis


 wrote:


 There is no semantic difference between

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

 and

 foo(S(2));


 There's a _huge_ difference between those two. In the first




 case, you

 have a
 variable which exists beyond the end of the function call.




 In the

 second, you
 have temporary which is destroyed as soon as the statement




 has completed.

 Still, there is no semantic difference. I know this issue from 
 C++. At first I had embraced it but I am not so sure anymore. 
 The language is getting out of its way to protect the 
 programmer. A language like C++ that gives so much freedom to 
 do many other unsafe things...


Why do you think there is no semantic difference?


 Constructors and functions do not affect objects alone. However 
 frowned upon, a function that is called on an S may have 
 side-effects that are beyond the object itself. If foo() does 
 s.bar() and S.bar has a side-effect, I wouldn't care about the 
 changes on the rvalue object itself.


Even if one particular function makes some side effects and does 
not care by taking ref parameter that changes may be discarded, 
it is a source of bugs in general, when taking argument by ref 
means that passed object must be modified and changes need to be 
preserved.



 Jan 05 2013



  parent  =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com>  writes:


On 01/05/2013 11:34 AM, Maxim Fomin wrote:

 On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:



 There is no semantic difference between

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

 and

 foo(S(2));











 Still, there is no semantic difference.





 Why do you think there is no semantic difference?


I took the example with an assumed scope around the first line:

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

That's why all I see is that an S object is constructed and passed to 
foo(). Same as the following:

     foo(S(2));


 Constructors and functions do not affect objects alone. However
 frowned upon, a function that is called on an S may have side-effects
 that are beyond the object itself. If foo() does s.bar() and S.bar has
 a side-effect, I wouldn't care about the changes on the rvalue object
 itself.


 Even if one particular function makes some side effects and does not
 care by taking ref parameter that changes may be discarded, it is a
 source of bugs in general, when taking argument by ref means that passed
 object must be modified and changes need to be preserved.


I agree that perhaps a number of my bugs have been avoided by that. I 
still find it too intrusive of the language when it assumes that the 
changes to the object are important as well.

Yet, the language has no interest in e.g. the return values that may not 
be consumed completely:

     vector<int> v = makeVector();
     cout << vector[0];
     // Oops! Have I forgotten vector[1] or did I simply not care?

I see it the same issue with ref parameters. foo() may call 
s.nonConstFunc(), which may have two effects: A side-effect and a 
modification to the object. Why would I not be allowed to not care about 
the latter similar to how I did not care about vector[1]? That's my point.

Again though, perhaps this rule has protected me more than it brought 
inconveniences.

Ali



 Jan 05 2013



prev sibling  parent reply "js.mdnq" <js_adddot+mdng gmail.com>  writes:


On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote:

 On Friday, January 04, 2013 13:12:52 js.mdnq wrote:

 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));


 There's a _huge_ difference between those two. In the first 
 case, you have a
 variable which exists beyond the end of the function call. In 
 the second, you
 have temporary which is destroyed as soon as the statement has 
 completed.


Nope, sorry, it's not. That is only a compiler optimization. Just 
because the compiler decides to do something to make them 
different does not mean they are. The compiler could easily just 
make S(2) null for no obvious reason because it wants to.

But if the compiler decides to make a different because of some 
reason(such as optimization then it also can decide to not do so.

For example, tell me why the compiler can't just expand

    foo(S(2));

to

    S ___s = S(2);
    foo(___s)

where ___s is hidden?

Then there is obviously no difference. But nothing is stopping 
the compiler from doing so and in fact, it could be doing so 
already unless you know it's not. If it did do such a hidden 
expansion then you would agree that the two cases are identical? 
(if not then there is no point is discussing any further because 
we can't even agree on basic logic)

Now, if the compiler decides to optimize the first case 
differently then the second case, that is not because they are 
different but because who ever write the code thinks they are.

Just because something looks different from something else does 
not mean they are.



 Jan 04 2013



  parent reply "Jonathan M Davis" <jmdavisProg gmx.com>  writes:


On Friday, January 04, 2013 21:47:42 js.mdnq wrote:

 On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote:

 On Friday, January 04, 2013 13:12:52 js.mdnq wrote:

 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));


 
 There's a _huge_ difference between those two. In the first
 case, you have a
 variable which exists beyond the end of the function call. In
 the second, you
 have temporary which is destroyed as soon as the statement has
 completed.


 
 Nope, sorry, it's not. That is only a compiler optimization. Just
 because the compiler decides to do something to make them
 different does not mean they are. The compiler could easily just
 make S(2) null for no obvious reason because it wants to.
 
 But if the compiler decides to make a different because of some
 reason(such as optimization then it also can decide to not do so.
 
 For example, tell me why the compiler can't just expand
 
 foo(S(2));
 
 to
 
 S ___s = S(2);
 foo(___s)
 
 where ___s is hidden?


S(2) _must_ leave scope after the statement foo(S(2)) completes, whereas with

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

the variable must continue to exist after foo(s) completes. That's 
fundamentally different. We're _not_ talking about compiler optimizations here. 
We're talking about the semantics of how the code works. And creating a 
variable on the stack would change the code's semantics, especially because 
foo(S(2)) should involve a move operation, whereas creating a variable on the 
stack would require that the object be destroyed after the call to foo. But 
even if declaring a hidden variable didn't change the semantics, __s must be 
destroyed once the statement with foo has completed, so it won't exist beyond 
the call to foo (it can't or it would alter the semantics of the code), so 
it's still fundamentally different from declaring a variable and passing it to 
foo, since the variable must continue to exist afterwards whereas the 
temporary must be gone.

- Jonathan M Davis



 Jan 04 2013



  parent reply "js.mdnq" <js_adddot+mdng gmail.com>  writes:


On Friday, 4 January 2013 at 20:59:44 UTC, Jonathan M Davis wrote:

 On Friday, January 04, 2013 21:47:42 js.mdnq wrote:

 On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis 
 wrote:

 On Friday, January 04, 2013 13:12:52 js.mdnq wrote:

 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));


 
 There's a _huge_ difference between those two. In the first
 case, you have a
 variable which exists beyond the end of the function call. In
 the second, you
 have temporary which is destroyed as soon as the statement 
 has
 completed.


 
 Nope, sorry, it's not. That is only a compiler optimization. 
 Just
 because the compiler decides to do something to make them
 different does not mean they are. The compiler could easily 
 just
 make S(2) null for no obvious reason because it wants to.
 
 But if the compiler decides to make a different because of some
 reason(such as optimization then it also can decide to not do 
 so.
 
 For example, tell me why the compiler can't just expand
 
 foo(S(2));
 
 to
 
 S ___s = S(2);
 foo(___s)
 
 where ___s is hidden?


 S(2) _must_ leave scope after the statement foo(S(2)) 
 completes, whereas with

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

 the variable must continue to exist after foo(s) completes. 
 That's
 fundamentally different. We're _not_ talking about compiler 
 optimizations here.
 We're talking about the semantics of how the code works. And 
 creating a
 variable on the stack would change the code's semantics, 
 especially because
 foo(S(2)) should involve a move operation, whereas creating a 
 variable on the
 stack would require that the object be destroyed after the call 
 to foo. But
 even if declaring a hidden variable didn't change the 
 semantics, __s must be
 destroyed once the statement with foo has completed, so it 
 won't exist beyond
 the call to foo (it can't or it would alter the semantics of 
 the code), so
 it's still fundamentally different from declaring a variable 
 and passing it to
 foo, since the variable must continue to exist afterwards 
 whereas the
 temporary must be gone.

 - Jonathan M Davis



Nope, technically the "struct literal" does not go out of scope 
because it exists on the stack till the end of the outer scope... 
just as the local variable does. As I said, it is equivalent, due 
to the substitution principle to the hidden variable:

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

because

foo(S(2)) can be shorthand for "hidden S __s = S(2); foo(s);"

(so, computationally these would all(or should) produce identical 
results).

You are saying because "visually" foo(S(2)) leaves the "scope" it 
is different than the others. This is true, but only visually(or 
syntactically). But the compiler could give you access to the 
hidden variable and then you would be wrong(it would not go out 
of scope).

Scope is not a physical but logical syntactical construct imposed 
by the compiler to help the user break a complex structure into 
nested units.

an only possibility would be something like:

e.g., we could have (pseudo)

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

identical to

   hidden S __s = S(2); // hidden
   foo(__s);  // but seen has foo(S(2)) by user
   clear(__s); // hidden


and so both cases, as the original are the same.

The only way you would be right is if we had:


   hidden S __s = S(2); // hidden
   foowrap(__s);  // but seen has foo(S(2)) by user

   foowrap(ref S s) if (s is hidden) { foo(s); clear(s); } else { 
foo(s); }

BUT then we could still have

   S s = S(2);
   foowrap(s);


The proof is in the pudding:

The statement:

foo(S(2));

causes the compiler to "create" the struct S(2) on the stack at 
some location or puts the value into registers(these methods are 
essentially identical, at the very least for our purpose, one 
being faster and having some limitations). We'll assume S(2) 
exists on the stack as an identical* argument can be made for the 
registers

foo is passed a ptr to a memory location on the stack. foo does 
what it does and returns. S(2) still exists at the same memory 
location on the stack after the return call(possibly modified).

Now, take the statement:

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

The exact same argument is used except we would replace S(2) with 
s so to speak. The compiler "creates" s on the stack, passes it 
to foo, and returns.

Both cases the stack is "cleaned" up at the end of the scope. So, 
the difference you are talking about is only due to the compiler 
hiding the variable. To show that it is not we could have a 
compiler construct:

foo(S(2));
foo!LastArgument; // (the hidden variable used by the compiler)

in which case, using the notation I've used before,

foo!LastArgument == __s;

Hence, such a **compiler** construct rectifies the issue you are 
talking about which proves that with foo(S(2)), S(2) only goes 
out of scope logically due to the compiler not providing such a 
construct but what I have talked about with the stack/registers 
shows that they do not go out of scope physically(so to speak).

I mean, I agree with you, except the part about "fundamental", in 
the statement you have said, but it is a different argument as it 
is all about how the compiler deals with it, which is what I said 
initially that it is part of the compiler but there is no 
semantic difference.

Obviously there is a symbolic difference, there is a difference 
in syntax, but those differences are for wusses. Real men see 
things abstractly and realize that function is more important 
than form! (well, unless we are talking about women then it 
becomes much more difficult ;)



 Jan 05 2013



 next sibling parent reply "Mehrdad" <wfunction hotmail.com>  writes:


On Saturday, 5 January 2013 at 12:58:49 UTC, js.mdnq wrote:

 You are saying because "visually" foo(S(2)) leaves the "scope" 
 it is different than the others.



No, he is saying so because the LANGUAGE (and I don't mean the 
_compiler_) defines what "scope" means, and it also defines when 
anything enters/leaves some scope.

It also defines the lifetimes of variables, and for structs, 
that's bounded to their scope.


Your perception of what *COULD* have been an alternate definition 
(or implementation) has zero bearing on anything, because that's 
not what it means in D, period.



 Jan 05 2013



  parent reply "js.mdnq" <js_adddot+mdng gmail.com>  writes:


On Saturday, 5 January 2013 at 18:38:31 UTC, Mehrdad wrote:

 On Saturday, 5 January 2013 at 12:58:49 UTC, js.mdnq wrote:

 You are saying because "visually" foo(S(2)) leaves the "scope" 
 it is different than the others.



 No, he is saying so because the LANGUAGE (and I don't mean the 
 _compiler_) defines what "scope" means, and it also defines 
 when anything enters/leaves some scope.

 It also defines the lifetimes of variables, and for structs, 
 that's bounded to their scope.


 Your perception of what *COULD* have been an alternate 
 definition (or implementation) has zero bearing on anything, 
 because that's not what it means in D, period.



Oh please, 90% of the discussions on here are about what d is 
doing, should do, and will do, period!

The discussion came about because a change in the 
compiler/language and regardless of how you want to spin it, D's 
language specification is not set in stone and is not implemented 
perfectly in the compiler... and even if it were, it doesn't then 
mean that it does it the best way.



 Jan 05 2013



  parent  "Rob T" <rob ucora.com>  writes:


On Saturday, 5 January 2013 at 21:24:48 UTC, js.mdnq wrote:

 Oh please, 90% of the discussions on here are about what d is 
 doing, should do, and will do, period!

 The discussion came about because a change in the 
 compiler/language and regardless of how you want to spin it, 
 D's language specification is not set in stone and is not 
 implemented perfectly in the compiler... and even if it were, 
 it doesn't then mean that it does it the best way.


The root problem, which I mentioned in an earlier post in this 
thread (that unfortunately caused the diversion into patching up 
the .mobi file), is that D does not actually have a specification 
because the specification is not being properly managed. To me, 
this is a significant problem that needs to be taken on as soon 
as possible - we need a solid official specification that 
contains at least revision numbers for tracking purposes and 
linking to the compiler releases, among other obvious advantages.

What we have ATM is not being managed in a sane and efficient way 
and can never be pinned down. The specification is actually 
spread out between what is on this web site, partly hidden away 
in forum postings, and what is in the TDPL book (and I probably 
missed a location or two). I cannot think of a situation much 
worse than this, yet here we are. If we can survive with this, 
then imagine how much better we'll be with at least some thought 
put into consolidating the specification into a managed document.

Rather than arguing endlessly over something that has no answer, 
we instead need to get organized and pin down the specification 
into a well managed form. We can do this by doing exactly the 
same things that we're doing with implementing the development 
and release process, i.e., we need a process for managing the 
specification, and we need a document that can be managed in 
similar ways (although likely not identical) to how the software 
is now being manged.

I'm certain there are a few people reading this who know what I'm 
talking about, and who have much more experience in how to manage 
something like a specification. So if anyone wants to step up and 
lend a hand, now may be a good time. There's really no reason for 
delaying what needs to be done.

--rt



 Jan 05 2013



prev sibling next sibling parent  Jonathan M Davis <jmdavisProg gmx.com>  writes:


On Saturday, January 05, 2013 13:58:48 js.mdnq wrote:

 Nope, technically the "struct literal" does not go out of scope
 because it exists on the stack till the end of the outer scope...
 just as the local variable does. As I said, it is equivalent, due
 to the substitution principle to the hidden variable:
 
 S s = S(2); foo(s) <==> foo(S(2))
 
 because
 
 foo(S(2)) can be shorthand for "hidden S __s = S(2); foo(s);"
 
 (so, computationally these would all(or should) produce identical
 results).
 
 You are saying because "visually" foo(S(2)) leaves the "scope" it
 is different than the others. This is true, but only visually(or
 syntactically). But the compiler could give you access to the
 hidden variable and then you would be wrong(it would not go out
 of scope).
 
 Scope is not a physical but logical syntactical construct imposed
 by the compiler to help the user break a complex structure into
 nested units.


No offense. I'm afraid that you simply have no clue what you're talking about. 
Scope is defined by the language. And temporaries leave scope when the 
statement that they're in completes. And these examples in both D and C++ show 
that that's the case:

------------
import std.stdio;

struct S
{
    this(int i)
    {
        this.i = i;
        writeln("Constructed!");
    }

    ~this()
    {
        writeln("Destroyed!");
    }

    int i;
}

void foo(S s)
{
    writeln("foo!");
}

void main()
{
    writeln("before");
    foo(S(5));
    writeln("after");
}
------------

------------
#include <cstdio>
using namespace std;

struct S
{
    S(int i)
    {
        this->i = i;
        printf("Constructed!\n");
    }

    ~S()
    {
        printf("Destroyed!\n");
    }

    int i;
};

void foo(S s)
{
    printf("foo!\n");
}

int main()
{
    printf("before\n");
    foo(S(5));
    printf("after\n");

    return 0;
}
------------

They both print

before
Constructed!
foo!
Destroyed!
after

If the struct literal continued to exist after the call to foo, "Destroyed!" 
would have printed after "after," but it printed before "after" in both cases.

This is required by the language, and it's precisely why doing things like 
taking the address of a temporary are so incredibly foolish to do.

- Jonathan M Davis



 Jan 05 2013



prev sibling  parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com>  writes:


On 01/05/2013 04:58 AM, js.mdnq wrote:


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


For those to be equivalent, there must be a scope around the first one:

{ S s = S(2); foo(s); } <==> foo(S(2))

I think that's what you've been proposing: The compiler could generate a 
variable on the stack to be passed to the function that takes ref.

It would still have the problem of losing potential modifications to the 
variable, which both C++ and D try to protect the programmer from.

Ali



 Jan 05 2013



  parent  "deadalnix" <deadalnix gmail.com>  writes:


On Sunday, 6 January 2013 at 06:14:56 UTC, Ali Çehreli wrote:

 On 01/05/2013 04:58 AM, js.mdnq wrote:


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


 For those to be equivalent, there must be a scope around the 
 first one:

 { S s = S(2); foo(s); } <==> foo(S(2))

 I think that's what you've been proposing: The compiler could 
 generate a variable on the stack to be passed to the function 
 that takes ref.


The compiler must, not could. It have to create the variable on 
the stack in order to execute the constructor.


 It would still have the problem of losing potential 
 modifications to the variable, which both C++ and D try to 
 protect the programmer from.

 Ali





 Jan 06 2013