digitalmars.D - WTF did happen with struct constructor and ref in 2.061 ?
- deadalnix (7/7) Jan 03 2013 I find myself with massive breakage in my codebase. I have a lot
- Jonathan M Davis (28/37) Jan 03 2013 http://d.puremagic.com/issues/show_bug.cgi?id=9069
- deadalnix (9/54) Jan 03 2013 This has been discussed, but I'm pretty sure nothing was really
- Rob T (22/27) Jan 03 2013 I have several times now pointed out in different threads that we
- Andrei Alexandrescu (7/26) Jan 03 2013 What's the link?
- Rob T (19/30) Jan 03 2013 http://dlang.org/download.html
- Andrei Alexandrescu (3/5) Jan 03 2013 What's wrong with the book?
- Rob T (11/12) Jan 03 2013 The bad link is also here, including the Amazon link.
- Andrei Alexandrescu (11/22) Jan 03 2013 This is a misunderstanding and I confess I'm mildly miffed by it. The
- Rob T (18/29) Jan 03 2013 Sorry, I didn't want to offend and I honestly never thought
- Jacob Carlborg (7/18) Jan 04 2013 There's a link on the top of that page, "Mobi ebook", which links to
- Andrei Alexandrescu (3/20) Jan 04 2013 Got it, thanks. Will fwd to Walter.
- Jordi Sayol (4/30) Jan 04 2013 dlangspec.mobi is back! :-)
- Andrei Alexandrescu (3/4) Jan 04 2013 Did my best to fix it. All, please take a look.
- Jordi Sayol (14/21) Jan 04 2013 I found these things:
- Andrei Alexandrescu (7/25) Jan 04 2013 Thanks a bunch! I made one more pass and fixed the excessively large
- Jordi Sayol (7/40) Jan 04 2013 Great work! All these things properly shown on Calibre too.
- Jordi Sayol (4/45) Jan 04 2013 In "Table of contents", last chapter "Vector Extensions" is missing.
- Philippe Sigaud (4/5) Jan 05 2013 Calibre does not open it here (Linux, KDE) not does it accept to conver...
- Jordi Sayol (4/7) Jan 05 2013 No problem open the last http://dlang.org/dlangspec.mobi (built by andra...
- Philippe Sigaud (7/14) Jan 05 2013 Calibre 0.8.64 here. Still does not work.
- Andrei Alexandrescu (5/8) Jan 05 2013 https://github.com/D-Programming-Language/d-programming-language.org/blo...
- Philippe Sigaud (1/10) Jan 06 2013 Thanks a lot.
- Rob T (11/15) Jan 04 2013 Thanks Andrei!
- Nick Sabalausky (20/38) Jan 05 2013 It's an ebook version of the content on dlang.org, right? That should
- Andrei Alexandrescu (7/23) Jan 05 2013 Walter and I discussed this matter for a while and reached a different
- Nick Sabalausky (8/34) Jan 05 2013 Amazon's reach is irrelevant given the bigger issue.
- Andrei Alexandrescu (4/38) Jan 05 2013 That's not my perception at all, which signals we might have reached
- David Nadlinger (7/8) Jan 06 2013 Too bad. It seems that the whole discussion could be resolved by
- Andrei Alexandrescu (3/9) Jan 06 2013 I think that's a great idea, will do.
- Andrei Alexandrescu (9/19) Jan 06 2013 Submitted this review:
- Philippe Sigaud (4/13) Jan 06 2013 Could you explain somewhere how the .mobi is generated? (Not in the revi...
- Andrei Alexandrescu (4/18) Jan 06 2013 It's all in posix.mak on github.
- Nick Sabalausky (18/59) Jan 05 2013 I'll put it another way: We've had public perception troubles in the
- Jacob Carlborg (4/13) Jan 06 2013 It's possible to read arbitrary PDF files on a Kindle.
- Nick Sabalausky (3/18) Jan 06 2013 Good, then there really is no need for the paid version on Amazon.
- Andrei Alexandrescu (6/11) Jan 04 2013 I've added the .mobi build to the regular site build. Unfortunately, I'm...
- Namespace (4/4) Jan 03 2013 You could use 'auto ref'. It isn't offical implemented, but I use
- Jacob Carlborg (4/9) Jan 04 2013 I had the same problem. Thank god I saw this thread.
- js.mdnq (17/63) Jan 04 2013 can you show an example of such a bug? I assume you mean that a
- Maxim Fomin (44/48) Jan 04 2013 In the first case dtor (if any) is called at the end of the
- Jonathan M Davis (30/42) Jan 04 2013 There's a _huge_ difference between those two. In the first case, you ha...
- deadalnix (24/83) Jan 04 2013 This may not have a storage :
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (44/101) Jan 04 2013 completed.
- deadalnix (13/43) Jan 04 2013 This is where things are subtle. Depending on the calling
- =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= (3/13) Jan 05 2013 Although, nothing stops the compiler from initializing a struct in a reg...
- deadalnix (6/22) Jan 06 2013 In this case, this is a register promotion that happen as an
- Maxim Fomin (7/36) Jan 05 2013 Even if one particular function makes some side effects and does
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (21/40) Jan 05 2013 I took the example with an assumed scope around the first line:
- js.mdnq (24/45) Jan 04 2013 Nope, sorry, it's not. That is only a compiler optimization. Just
- Jonathan M Davis (17/59) Jan 04 2013 S(2) _must_ leave scope after the statement foo(S(2)) completes, whereas...
- js.mdnq (77/156) Jan 05 2013 Nope, technically the "struct literal" does not go out of scope
- Mehrdad (9/11) Jan 05 2013 No, he is saying so because the LANGUAGE (and I don't mean the
- js.mdnq (8/19) Jan 05 2013 Oh please, 90% of the discussions on here are about what d is
- Rob T (31/38) Jan 05 2013 The root problem, which I mentioned in an earlier post in this
- Jonathan M Davis (70/93) Jan 05 2013 No offense. I'm afraid that you simply have no clue what you're talking ...
- =?UTF-8?B?QWxpIMOHZWhyZWxp?= (8/9) Jan 05 2013 For those to be equivalent, there must be a scope around the first one:
- deadalnix (3/15) Jan 06 2013 The compiler must, not could. It have to create the variable on
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
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
On Thursday, 3 January 2013 at 23:40:39 UTC, Jonathan M Davis wrote:On Friday, January 04, 2013 00:20:58 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 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.But the struct storage is passed to the constructor ! It has an actual storage !
Jan 03 2013
On Thursday, 3 January 2013 at 23:57:19 UTC, deadalnix wrote:This has been discussed, but I'm pretty sure nothing was really conclusive (especially when I read about auto ref). And even if it was, how come that this isn't advertised with some big red sign ? If a person that read the newsgroup like me didn't see that coming, what about any regular D user ?I have several times now pointed out in different threads that we have a *big* problem concerning the lack of a process for defining and implementing the D specification. It is very encouraging that we're now attempting to solve some big issues with the development and release process, but it only concerns the branching methods and movement of new code into a stable form. The next big ticket, which IMO is much more significant a change, is to define a process for managing the D specification in a more sensible way, in fact there is no process that I'm aware of, and if there is one it's totally dysfunctional. At some point this problem has to be dealt with as it's a massive inhibitor for anyone to take D seriously. For example, try downloading the specification and you'll get http 404, or you get a link to some ancient crap from Amazon for .99 cents - seriously! Try finding the most current version of the specification (there is no version to speak of). What's being proposed for the next big change? There's are DIPS, but where are they and how are they linked to the endless discussions surrounding them? Etc. I hope this major issue gets serious attention in the new year after 2.061 is released. --rt
Jan 03 2013
On 1/3/13 7:14 PM, Rob T wrote:I have several times now pointed out in different threads that we have a *big* problem concerning the lack of a process for defining and implementing the D specification. It is very encouraging that we're now attempting to solve some big issues with the development and release process, but it only concerns the branching methods and movement of new code into a stable form. The next big ticket, which IMO is much more significant a change, is to define a process for managing the D specification in a more sensible way, in fact there is no process that I'm aware of, and if there is one it's totally dysfunctional.Agreed.At some point this problem has to be dealt with as it's a massive inhibitor for anyone to take D seriously. For example, try downloading the specification and you'll get http 404, or you get a link to some ancient crap from Amazon for .99 cents - seriously!What's the link?Try finding the most current version of the specification (there is no version to speak of). What's being proposed for the next big change? There's are DIPS, but where are they and how are they linked to the endless discussions surrounding them? Etc.All good points.I hope this major issue gets serious attention in the new year after 2.061 is released.This looks like written from back in time. Yes it is getting attention, I hoped at least as much is obvious by now. Andrei
Jan 03 2013
On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote: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.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?This looks like written from back in time. Yes it is getting attention, I hoped at least as much is obvious by now. AndreiYes 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
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/B005CCQPKKWhat's wrong with the book? Andrei
Jan 03 2013
On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:What's the link?The bad link is also here, including the Amazon link. http://dlang.org/spec.html The problem link and the Amazon e-book issue has been mentioned multiple times before and as recently as Nov last year. I like the idea of the e-book but we need an up-to-date copy and it should be available free of charge. If the D community needs funding, a method of making donations is a much better and more acceptable route to take. --rt
Jan 03 2013
On 1/3/13 11:26 PM, Rob T wrote:On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:I don't understand what the "issue" is.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.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
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. AndreiSorry, 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
On 2013-01-04 05:32, Andrei Alexandrescu wrote:On 1/3/13 11:26 PM, Rob T wrote: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 CarlborgOn Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:I don't understand what the "issue" is.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.
Jan 04 2013
On 1/4/13 6:11 AM, Jacob Carlborg wrote:On 2013-01-04 05:32, Andrei Alexandrescu wrote:Got it, thanks. Will fwd to Walter. AndreiOn 1/3/13 11:26 PM, Rob T wrote: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.On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:I don't understand what the "issue" is.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.
Jan 04 2013
Al 04/01/13 18:17, En/na Andrei Alexandrescu ha escrit:On 1/4/13 6:11 AM, Jacob Carlborg wrote:dlangspec.mobi is back! :-) -- Jordi SayolOn 2013-01-04 05:32, Andrei Alexandrescu wrote:Got it, thanks. Will fwd to Walter. AndreiOn 1/3/13 11:26 PM, Rob T wrote: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.On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote:I don't understand what the "issue" is.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.
Jan 04 2013
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
Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit:On 1/4/13 5:44 PM, Jordi Sayol wrote: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 Sayoldlangspec.mobi is back! :-)Did my best to fix it. All, please take a look. Andrei
Jan 04 2013
On 1/4/13 6:59 PM, Jordi Sayol wrote:Al 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit: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, AndreiOn 1/4/13 5:44 PM, Jordi Sayol wrote: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).dlangspec.mobi is back! :-)Did my best to fix it. All, please take a look. Andrei
Jan 04 2013
Al 05/01/13 03:05, En/na Andrei Alexandrescu ha escrit:On 1/4/13 6:59 PM, Jordi Sayol wrote: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 SayolAl 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit: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,On 1/4/13 5:44 PM, Jordi Sayol wrote: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).dlangspec.mobi is back! :-)Did my best to fix it. All, please take a look. Andrei
Jan 04 2013
Al 05/01/13 03:42, En/na Jordi Sayol ha escrit:Al 05/01/13 03:05, En/na Andrei Alexandrescu ha escrit:In "Table of contents", last chapter "Vector Extensions" is missing. -- Jordi SayolOn 1/4/13 6:59 PM, Jordi Sayol wrote: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-VhAl 05/01/13 00:03, En/na Andrei Alexandrescu ha escrit: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,On 1/4/13 5:44 PM, Jordi Sayol wrote: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).dlangspec.mobi is back! :-)Did my best to fix it. All, please take a look. Andrei
Jan 04 2013
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
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
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 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.Calibre does not open it here (Linux, KDE) not does it accept toconvert it.No problem open the last http://dlang.org/dlangspec.mobi (built by andralex) with Calibre v0.8.38 (Linux 64-bit, Mate)
Jan 05 2013
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
Andrei, would that be possible to give us access to the .css that givesThanks a lot.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.
Jan 06 2013
On Friday, 4 January 2013 at 23:03:32 UTC, Andrei Alexandrescu wrote:On 1/4/13 5:44 PM, Jordi Sayol wrote: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. --rtdlangspec.mobi is back! :-)Did my best to fix it. All, please take a look. Andrei
Jan 04 2013
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: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.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.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
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: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. AndreiOn 1/3/13 11:26 PM, Rob T 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.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.
Jan 05 2013
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:Amazon's reach is irrelevant given the bigger issue.On Thu, 03 Jan 2013 23:32:45 -0500 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:Walter and I discussed this matter for a while and reached a different conclusion. Amazon has good distribution which we found worthwhile.On 1/3/13 11:26 PM, Rob T 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.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.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
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:That's not my perception at all, which signals we might have reached irreducible positions. I won't discuss this further. AndreiOn 1/6/13 12:01 AM, Nick Sabalausky wrote:Amazon's reach is irrelevant given the bigger issue.On Thu, 03 Jan 2013 23:32:45 -0500 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:Walter and I discussed this matter for a while and reached a different conclusion. Amazon has good distribution which we found worthwhile.On 1/3/13 11:26 PM, Rob T 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.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.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
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
On 1/6/13 11:52 AM, David Nadlinger wrote:On Sunday, 6 January 2013 at 06:06:21 UTC, Andrei Alexandrescu wrote:I think that's a great idea, will do. AndreiI 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.
Jan 06 2013
On 1/6/13 2:39 PM, Andrei Alexandrescu wrote:On 1/6/13 11:52 AM, David Nadlinger 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. 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! AndreiOn Sunday, 6 January 2013 at 06:06:21 UTC, Andrei Alexandrescu wrote:I think that's a great idea, will do. AndreiI 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.
Jan 06 2013
On Sun, Jan 6, 2013 at 8:49 PM, Andrei Alexandrescu < SeeWebsiteForEmail erdani.org> wrote:Could you explain somewhere how the .mobi is generated? (Not in the review, of course, but on the newsgroup)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.
Jan 06 2013
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
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: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.)On 1/6/13 12:01 AM, Nick Sabalausky wrote:Amazon's reach is irrelevant given the bigger issue.On Thu, 03 Jan 2013 23:32:45 -0500 Andrei Alexandrescu<SeeWebsiteForEmail erdani.org> wrote:Walter and I discussed this matter for a while and reached a different conclusion. Amazon has good distribution which we found worthwhile.On 1/3/13 11:26 PM, Rob T 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.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.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
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
On Sun, 06 Jan 2013 12:44:13 +0100 Jacob Carlborg <doob me.com> wrote:On 2013-01-06 06:01, Nick Sabalausky wrote:Good, then there really is no need for the paid version on Amazon.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.
Jan 06 2013
On 1/3/13 11:26 PM, Rob T wrote:On Friday, 4 January 2013 at 00:59:01 UTC, Andrei Alexandrescu wrote: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. AndreiWhat's the link?The bad link is also here, including the Amazon link. http://dlang.org/spec.html
Jan 04 2013
You could use 'auto ref'. It isn't offical implemented, but I use it already. See also this thread: http://forum.dlang.org/thread/tkzyjhshbqjqxwzppdin forum.dlang.org?page=7
Jan 03 2013
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
On Thursday, 3 January 2013 at 23:40:39 UTC, Jonathan M Davis wrote:On Friday, January 04, 2013 00:20:58 deadalnix 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)); 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)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 04 2013
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
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
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: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.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());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
On 01/04/2013 10:48 AM, deadalnix wrote:On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote: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.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 hasAgreed.Where there's no real difference is foo(S(2)); foo(funcThatReturnsS());I don't see that. funcThatReturnsS returns an S, which must have a storage as well.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.beyond theAlso, 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 lastsGetting back to this issue: So what? I have one more bug in my code.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 ?I agree with all of that. (Although, the French grammar rule of that space before the question mark is hurting my eyes! :p)I hope D's 'auto ref' solution solves this issue once and for all. :)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),struct Bar { uint i; this(uint foo) { import std.stdio; writeln(&this); } } void main() { Bar(0); }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 AliThere 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.
Jan 04 2013
On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote: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.This may not have a storage : foo(funcThatReturnsS());I don't see that. funcThatReturnsS returns an S, which must have a storage as well.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 :DYou 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.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
Am 04.01.2013 20:35, schrieb deadalnix:On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:Although, nothing stops the compiler from initializing a struct in a register either. At least when the constructor can be inlined.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.This may not have a storage : foo(funcThatReturnsS());I don't see that. funcThatReturnsS returns an S, which must have a storage as well.
Jan 05 2013
On Saturday, 5 January 2013 at 21:23:20 UTC, Sönke Ludwig wrote:Am 04.01.2013 20:35, schrieb deadalnix: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.On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:Although, nothing stops the compiler from initializing a struct in a register either. At least when the constructor can be inlined.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.This may not have a storage : foo(funcThatReturnsS());I don't see that. funcThatReturnsS returns an S, which must have a storage as well.
Jan 06 2013
On Friday, 4 January 2013 at 19:15:03 UTC, Ali Çehreli wrote:On 01/04/2013 10:48 AM, deadalnix wrote:Why do you think there is no semantic difference?On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Daviswrote:case, youThere 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 firstIn thehave a variable which exists beyond the end of the function call.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...second, you have temporary which is destroyed as soon as the statementConstructors 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
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));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. AliConstructors 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
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: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.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.
Jan 04 2013
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: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 DavisOn Friday, January 04, 2013 13:12:52 js.mdnq wrote: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?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.
Jan 04 2013
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: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 ;)On Friday, 4 January 2013 at 16:47:38 UTC, Jonathan M Davis wrote: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 DavisOn Friday, January 04, 2013 13:12:52 js.mdnq wrote: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?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.
Jan 05 2013
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
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: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.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
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
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
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
On Sunday, 6 January 2013 at 06:14:56 UTC, Ali Çehreli wrote:On 01/05/2013 04:58 AM, js.mdnq wrote:The compiler must, not could. It have to create the variable on the stack in order to execute the constructor.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 06 2013