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
next sibling 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 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 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 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 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 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
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
parent 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
prev sibling 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 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 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 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 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
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 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 =?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


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 


 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 =?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
prev sibling 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 next sibling parent "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
prev sibling next sibling parent "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
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 next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling 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 next 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
parent =?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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent 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
prev sibling next 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 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:
--047d7bae49ec03f9a804d286f639
Content-Type: text/plain; charset=UTF-8

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. --047d7bae49ec03f9a804d286f639 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sat, Jan 5, 2013 at 3:05 AM, Andrei A= lexandrescu <span dir=3D"ltr">&lt;<a href=3D"mailto:SeeWebsiteForEmail erda= ni.org" target=3D"_blank">SeeWebsiteForEmail erdani.org</a>&gt;</span> wrot= e:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><div class=3D"im"><br></div> All - one more look please: <a href=3D"http://dlang.org/dlangspec.mobi" tar= get=3D"_blank">http://dlang.org/dlangspec.<u></u>mobi</a></blockquote><div>= <br></div><div>=C2=A0Calibre does not open it here (Linux, KDE) not does it= accept to convert it.</div> <div><br></div><div><br></div><div><br></div><div><br></div></div> --047d7bae49ec03f9a804d286f639--
Jan 05 2013
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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

 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


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


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


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
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 next sibling parent "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
prev sibling next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--047d7b6774d01e0b5c04d29209bf
Content-Type: text/plain; charset=UTF-8

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


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

(...) 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. --047d7b6774d01e0b5c04d29209bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><br><div class=3D"gmail_quote">On Sat, Jan 5, 2013 at 9:17 PM, Jordi Sa= yol <span dir=3D"ltr">&lt;<a href=3D"mailto:g.sayol yahoo.es" target=3D"_bl= ank">g.sayol yahoo.es</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"> Al 05/01/13 10:10, En/na Philippe Sigaud ha escrit:<br> <div class=3D"im">&gt;<br> &gt; =C2=A0Calibre does not open it here (Linux, KDE) not does it accept to= convert it.<br> &gt;<br> <br> </div>No problem open the last <a href=3D"http://dlang.org/dlangspec.mobi" = target=3D"_blank">http://dlang.org/dlangspec.mobi</a> (built by andralex) w= ith Calibre v0.8.38 (Linux 64-bit, Mate)<br><span class=3D"HOEnZb"><font co= lor=3D"#888888"><br> </font></span></blockquote><div><br></div><div>Calibre 0.8.64 here. Still d= oes not work.</div><div>(...)</div><div>I updated to 0.9.13 (latest version= ) and it works, yeah!</div><div><br></div><div>Andrei, would that be possib= le to give us access to the .css that gives the mobi file its global appear= ance? I&#39;d like D-related mobi/epub that I create to have the same look-= and-feel.</div> <div><br></div><div><br></div></div> --047d7b6774d01e0b5c04d29209bf--
Jan 05 2013
prev sibling next sibling 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 next sibling parent 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
prev sibling next sibling parent 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
prev sibling next 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 next sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--047d7b6777f22b52e504d29bad1c
Content-Type: text/plain; charset=UTF-8

  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. --047d7b6777f22b52e504d29bad1c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D= "im"> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Andrei, would that be possible to give us access to the .css that gives<br> the mobi file its global appearance? I&#39;d like D-related mobi/epub that = I<br> create to have the same look-and-feel.<br> </blockquote> <br> </div><a href=3D"https://github.com/D-Programming-Language/d-programming-la= nguage.org/blob/master/ebook.css" target=3D"_blank">https://github.com/D-<u=
</u>Programming-Language/d-<u></u>programming-language.org/blob/<u></u>mas=

<br> <a href=3D"https://github.com/D-Programming-Language/d-programming-language= .org/blob/master/ebook.ddoc" target=3D"_blank">https://github.com/D-<u></u>= Programming-Language/d-<u></u>programming-language.org/blob/<u></u>master/e= book.ddoc</a><br> <br> See also the makefile.</blockquote><div><br></div><div>Thanks a lot.</div><= div>=C2=A0</div></div> --047d7b6777f22b52e504d29bad1c--
Jan 06 2013
prev sibling next sibling 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 next sibling 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
prev sibling next sibling 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 next sibling parent "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
prev sibling parent Philippe Sigaud <philippe.sigaud gmail.com> writes:
--047d7b6774d067539d04d2a41fcb
Content-Type: text/plain; charset=UTF-8

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) --047d7b6774d067539d04d2a41fcb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Jan 6, 2013 at 8:49 PM, Andrei Alexandrescu <span dir=3D"ltr">&lt;<= a href=3D"mailto:SeeWebsiteForEmail erdani.org" target=3D"_blank">SeeWebsit= eForEmail erdani.org</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><b= lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5"><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>= </blockquote></div></div> Submitted this review:<br> <br> Official D language specification formatted for the Kindle<br> <br> We are producing this from the same source files as the online specificatio= n to be found at <a href=3D"http://dlang.org" target=3D"_blank">http://dlan= g.org</a>. The .mobi file is also freely downloadable from <a href=3D"http:= //dlang.org/dlangspec.mobi" target=3D"_blank">http://dlang.org/dlangspec.<u=
</u>mobi</a>. Please let the author know of any rendering issues. For disc=

f=3D"http://forum.dlang.org" target=3D"_blank">http://forum.dlang.org</a>. = Enjoy!<span class=3D"HOEnZb"><font color=3D"#888888"><br> <br></font></span></blockquote><div>That is quite good. Clear, to the point= and full of links.=C2=A0</div><div><br></div><div>Could you explain somewh= ere how the .mobi is generated? (Not in the review, of course, but on the n= ewsgroup)</div> <div><br></div><div><br></div></div> --047d7b6774d067539d04d2a41fcb--
Jan 06 2013