Re: Battle-plan for CTFE
On 2016-08-29 10:39, Stefan Koch wrote: Thanks guys. I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static assert(!__ctfe, "This function is not supposed to be called during ctfe"); similarly you can use static if (__ctfe). Is it worth trying to get it into master ? Wow, absolutely :) -- /Jacob Carlborg
Re: Battle-plan for CTFE
Am Tue, 30 Aug 2016 08:57:25 +0200 schrieb Jacob Carlborg : > On 2016-08-29 10:39, Stefan Koch wrote: > > > Thanks guys. > > > > I just came up with a nifty little patch that makes it possible to > > ensure that a function is _only_ used at ctfe. > > Or the opposite. > > > > static assert(__ctfe, "This function is not supposed to be called > > outside of ctfe"); > > and static assert(!__ctfe, "This function is not supposed to be > > called during ctfe"); > > > > similarly you can use static if (__ctfe). > > > > Is it worth trying to get it into master ? > > Wow, absolutely :) > There are some nice use cases for this: * Do not enforce @nogc for CTFE only functions, so you can mark a complete module nogc: and CTFE only functions will get ignored * Do not emit code for CTFE only functions. This is useful for bare metal programming: The CTFE only function can depend on druntime functions not available in the bare metal runtime. These are common problems when using string mixins: The functions to generate the mixed in code use string manipulation which is usually not @nogc and might require runtime functions. But the code generation function is exclusively used in CTFE.
Re: Battle-plan for CTFE
On Tuesday, 30 August 2016 at 08:18:47 UTC, Johannes Pfau wrote: There are some nice use cases for this: * Do not enforce @nogc for CTFE only functions, so you can mark a complete module nogc: and CTFE only functions will get ignored * Do not emit code for CTFE only functions. This is useful for bare metal programming: The CTFE only function can depend on druntime functions not available in the bare metal runtime. These are common problems when using string mixins: The functions to generate the mixed in code use string manipulation which is usually not @nogc and might require runtime functions. But the code generation function is exclusively used in CTFE. I do not see how this could affect @nogc. But yes you can circumvent the code-generation and pulling in the druntime dependency using a static if.
Re: Beta D 2.071.2-b2
On Tuesday, 9 August 2016 at 15:37:27 UTC, Martin Nowak wrote: Second beta for the 2.071.2 release. This fixes Issue 15780, 16085, and 16348. More import/lookup fixes upcoming. http://dlang.org/download.html#dmd_beta http://dlang.org/changelog/2.071.2.html Please report any bugs at https://issues.dlang.org - -Martin Could you consider this https://github.com/dlang/phobos/pull/4758, please
Re: Battle-plan for CTFE
On Tue, Aug 30, 2016 at 10:35 AM, Stefan Koch via Digitalmars-d-announce < digitalmars-d-announce@puremagic.com> wrote: > [snip] > But yes you can circumvent the code-generation and pulling in the druntime > dependency using a static if. > That will be awesome!
Re: Battle-plan for CTFE
Am Tue, 30 Aug 2016 08:35:20 + schrieb Stefan Koch : > I do not see how this could affect @nogc. @nogc is only meaningful at runtime. So this could work: module foo; @nogc: [...] string ctfeOnly(string name) { static assert(!__ctfe); // error: cannot use operator ~ in @nogc function return "int " ~ name ~ ";"; } mixin(ctfeOnly("foo"));
Re: Battle-plan for CTFE
Am Tue, 30 Aug 2016 12:42:35 +0200 schrieb Johannes Pfau : > @nogc is only meaningful at runtime. So this could work: > > module foo; > @nogc: > [...] > > string ctfeOnly(string name) > { > static assert(!__ctfe); This should be static assert(__ctfe); of course.
Joakim Intreviews Walter for the D Blog
Joakim has put together an interview with Walter that's all about D. It's an enjoyable read. You can parse the interview at [1] and visit the reddit thread at [2]. I anticipate publishing more of Joakim's interviews on the blog in the future. [1] https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/ [2] https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/
Re: The D Language Foundation is now a tax exempt non-profit organization
Andrei, This is splendid news for the purveying of the D Programming language. The question is though: this covers the USA what about the Rest of the World? For the language itself it is almost irrelevant where the owning foundation is located as long as it is a charitable venture in its jusridiction of incorporation. However for financial issues, the jurisdiction is critical. Getting USA-wide charitable status is great, well-done on that, particularly in the context of the atitude of IRS to charitable foundations a couple of years ago. However the EU and other parts of the world will not be covered by this, and I am not sure there is any form of reciprocal arrangement. On Mon, 2016-08-29 at 13:03 -0400, Andrei Alexandrescu via Digitalmars- d-announce wrote: > We're happy to report that the D Language Foundation is now a public > charity operating under US Internal Revenue Code Section 501(c)(3). > The > decision is retroactive to September 23, 2015. > > This has wide-ranging implications, the most important being that > individuals and organizations may make tax deductible bequests, > devises, > transfers, or gifts to the Foundation. We will mull over defining > donation and sponsorship packages in the near future. If interesting > in > donating spontaneously, feel free to reach out to us via email at > foundat...@dlang.org. > > Many thanks are due to the folks in this community who asked for and > supported this initiative. > > > > Thanks, > > Andrei -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Joakim Intreviews Walter for the D Blog
On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote: Joakim has put together an interview with Walter that's all about D. It's an enjoyable read. You can parse the interview at [1] and visit the reddit thread at [2]. I anticipate publishing more of Joakim's interviews on the blog in the future. [1] https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/ [2] https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/ Nice article. PS: "ABEL" link point to mobile version of wikipedia. Andrea
Re: Joakim Intreviews Walter for the D Blog
On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote: Joakim has put together an interview He did four (IIRC) of these for This Week in D too if you want more like that: Sönke Ludwig http://arsdnet.net/this-week-in-d/mar-15.html Dmitry Olshansky http://arsdnet.net/this-week-in-d/jun-28.html Etienne Cimon http://arsdnet.net/this-week-in-d/jul-12.html Atila Neves http://arsdnet.net/this-week-in-d/sep-06.html
Re: The D Language Foundation is now a tax exempt non-profit organization
On Tuesday, 30 August 2016 at 12:36:12 UTC, Russel Winder wrote: Andrei, This is splendid news for the purveying of the D Programming language. The question is though: this covers the USA what about the Rest of the World? For Germany this would probably require a separate application to the tax office to become a "gemeinnützige Organisation" (charitable organization). It seems [0] within the EU, it is enough for the donor to proof charity by including the charter in the tax declaration, but not for the US. [0] https://www.steuertipps.de/anlegen-vererben-spenden/themen/wann-sind-spenden-an-auslaendische-stiftungen-absetzbar
Re: The D Language Foundation is now a tax exempt non-profit organization
On 08/30/2016 08:36 AM, Russel Winder via Digitalmars-d-announce wrote: Andrei, This is splendid news for the purveying of the D Programming language. The question is though: this covers the USA what about the Rest of the World? For the language itself it is almost irrelevant where the owning foundation is located as long as it is a charitable venture in its jusridiction of incorporation. However for financial issues, the jurisdiction is critical. Getting USA-wide charitable status is great, well-done on that, particularly in the context of the atitude of IRS to charitable foundations a couple of years ago. However the EU and other parts of the world will not be covered by this, and I am not sure there is any form of reciprocal arrangement. Unless we have a sort of branch in other countries, I don't see what we can do here. -- Andrei
Re: Joakim Intreviews Walter for the D Blog
On Tuesday, 30 August 2016 at 13:37:34 UTC, Adam D. Ruppe wrote: On Tuesday, 30 August 2016 at 11:50:52 UTC, Mike Parker wrote: Joakim has put together an interview He did four (IIRC) of these for This Week in D too if you want more like that: Sönke Ludwig http://arsdnet.net/this-week-in-d/mar-15.html Dmitry Olshansky http://arsdnet.net/this-week-in-d/jun-28.html Etienne Cimon http://arsdnet.net/this-week-in-d/jul-12.html Atila Neves http://arsdnet.net/this-week-in-d/sep-06.html Thanks!
Re: Joakim Intreviews Walter for the D Blog
On Tuesday, 30 August 2016 at 13:07:03 UTC, Andrea Fontana wrote: Nice article. PS: "ABEL" link point to mobile version of wikipedia. Andrea Fixed, thanks!
Re: The D Language Foundation is now a tax exempt non-profit organization
On Tue, 2016-08-30 at 10:25 -0400, Andrei Alexandrescu via Digitalmars- d-announce wrote: […] > Unless we have a sort of branch in other countries, I don't see what > we > can do here. -- Andrei Understood, but without a solution it means no-one outside the USA can contribute and have the D Foundation receive the tax benefit of a charitable gift. From what I can tell PSF has't bothered to solve this, it is a USA organisation for USA people. Also I think donations are in US$, which means non-US$ donors bear the conversion cost. Someone has to because the banks are not charities, but it is annoying that non US$ donations get "taxed" twice. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: The D Language Foundation is now a tax exempt non-profit organization
On 08/30/2016 05:25 PM, Andrei Alexandrescu wrote: > Unless we have a sort of branch in other countries, I don't see what we > can do here. -- Andrei EU branch of D foundation would be interesting but I think it is much premature to think about that :) signature.asc Description: OpenPGP digital signature
Re: Battle-plan for CTFE
On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: On Monday, 29 August 2016 at 08:05:10 UTC, Rory McGuire wrote: On Mon, Aug 29, 2016 at 9:51 AM, Dominikus Dittes Scherkl via The work you are doing is just awesome! Many thanks. +1 your work is key for our success as a community. R Thanks guys. I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static assert(!__ctfe, "This function is not supposed to be called during ctfe"); similarly you can use static if (__ctfe). Is it worth trying to get it into master ? I would say maybe, but let's keep separate things separate. This is a language change. I would not include it in the same series of patch that change CTFE behavior.
Re: Battle-plan for CTFE
On Tuesday, 30 August 2016 at 17:29:19 UTC, deadalnix wrote: worth trying to get it into master ? I would say maybe, but let's keep separate things separate. This is a language change. I would not include it in the same series of patch that change CTFE behavior. Yes. It would be confusing. And it is not done with the patch I mentioned.
Beta D 2.071.2-b3
Third beta for the 2.071.2 release. This beta fixes spurious deprecation warnings with templates using getMember (Issue 15907), please read the changelog for more details. http://dlang.org/changelog/2.071.2.html http://dlang.org/download.html#dmd_beta Please report any bugs at https://issues.dlang.org -Martin
Re: Joakim Intreviews Walter for the D Blog
On 2016-08-30 13:50, Mike Parker wrote: Joakim has put together an interview with Walter that's all about D. It's an enjoyable read. You can parse the interview at [1] and visit the reddit thread at [2]. I anticipate publishing more of Joakim's interviews on the blog in the future. [1] https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/ Some of the links have pretty long text, is that intended? For example: "an early developer of C++ compilers starting from the mid-’80s, including the first C++ compiler to translate source code directly to object code without using C as an intermediate" All that is one link. -- /Jacob Carlborg
Re: Joakim Intreviews Walter for the D Blog
On 8/30/2016 4:50 AM, Mike Parker wrote: Joakim has put together an interview with Walter that's all about D. It's an enjoyable read. You can parse the interview at [1] and visit the reddit thread at [2]. I anticipate publishing more of Joakim's interviews on the blog in the future. [1] https://dlang.org/blog/2016/08/30/ruminations-on-d-an-interview-with-walter-bright/ [2] https://www.reddit.com/r/programming/comments/50aox1/ruminations_on_d_an_interview_with_walter_bright/ It's also on Hacker News, but access it via the front page rather than this URL, otherwise up/downvotes will not count: https://news.ycombinator.com/item?id=1239047
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote: Third beta for the 2.071.2 release. This beta fixes spurious deprecation warnings with templates using getMember (Issue 15907), please read the changelog for more details. http://dlang.org/changelog/2.071.2.html http://dlang.org/download.html#dmd_beta Please report any bugs at https://issues.dlang.org -Martin I'm a bit sad to see that https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored to fix issue 15907. Another decision could have been to break the visibility for the traits allMember, getMember, derivedMember and getOverloads.
Re: Battle-plan for CTFE
On Monday, 29 August 2016 at 08:39:56 UTC, Stefan Koch wrote: I just came up with a nifty little patch that makes it possible to ensure that a function is _only_ used at ctfe. Or the opposite. static assert(__ctfe, "This function is not supposed to be called outside of ctfe"); and static assert(!__ctfe, "This function is not supposed to be called during ctfe"); similarly you can use static if (__ctfe). Is it worth trying to get it into master ? Yes, please. I've often wished I could use `__ctfe` in a `static if`.
Re: Beta D 2.071.2-b3
On 08/30/2016 02:58 PM, Basile B. wrote: On Tuesday, 30 August 2016 at 19:37:25 UTC, Martin Nowak wrote: Third beta for the 2.071.2 release. This beta fixes spurious deprecation warnings with templates using getMember (Issue 15907), please read the changelog for more details. http://dlang.org/changelog/2.071.2.html http://dlang.org/download.html#dmd_beta Please report any bugs at https://issues.dlang.org -Martin I'm a bit sad to see that https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored to fix issue 15907. Another decision could have been to break the visibility for the traits allMember, getMember, derivedMember and getOverloads. +1 I've just opened a discussion thread on the main newsgroup about the (un)usability of this fix before seeing your comment. Ali
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote: I'm a bit sad to see that https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored to fix issue 15907. Another decision could have been to break the visibility for the traits allMember, getMember, derivedMember and getOverloads. Well there was reasoning to choose that solution instead of the other (https://github.com/dlang/dmd/pull/6078) and the fact that private members aren't accessible (set/get) is a good indication that nobody needs this. Adding an unsafe facility to access private members is a separate problem, but please see the changelog for how to achieve this already by mixing in templates.
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote: On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote: I'm a bit sad to see that https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored to fix issue 15907. Another decision could have been to break the visibility for the traits allMember, getMember, derivedMember and getOverloads. Well there was reasoning to choose that solution instead of the other (https://github.com/dlang/dmd/pull/6078) and the fact that private members aren't accessible (set/get) is a good indication that nobody needs this. As in needs private members in __traits(allMembers). Adding an unsafe facility to access private members is a separate problem, but please see the changelog for how to achieve this already by mixing in templates. Allowing access to private members has a lot of implications, e.g. breaks lots of optimizations b/c you can't know who accesses sth. It's also yet unclear what effect this has on @safe and we'd not only have to modify visibility but remove the access checks as well. This is clearly too much to just fix that problem w/ certain template instantiations, none of which should work on private members atm. Also you'd have to change a lot of existing code, or it would now just operate on private members.
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote: On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote: I'm a bit sad to see that https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored to fix issue 15907. Another decision could have been to break the visibility for the traits allMember, getMember, derivedMember and getOverloads. Well there was reasoning to choose that solution instead of the other (https://github.com/dlang/dmd/pull/6078) and the fact I don't understand, which was the other ? the link points to the PR that's been merged.
Re: Beta D 2.071.2-b3
On 08/30/2016 04:54 PM, Martin Nowak wrote: > On Tuesday, 30 August 2016 at 23:08:58 UTC, Martin Nowak wrote: >> On Tuesday, 30 August 2016 at 21:58:05 UTC, Basile B. wrote: >>> I'm a bit sad to see that >>> https://issues.dlang.org/show_bug.cgi?id=15371 was completely ignored >>> to fix issue 15907. Another decision could have been to break the >>> visibility for the traits allMember, getMember, derivedMember and >>> getOverloads. >> >> Well there was reasoning to choose that solution instead of the other >> (https://github.com/dlang/dmd/pull/6078) and the fact that private >> members aren't accessible (set/get) is a good indication that nobody >> needs this. > > As in needs private members in __traits(allMembers). > >> Adding an unsafe facility to access private members is a separate >> problem, but please see the changelog for how to achieve this already >> by mixing in templates. > > Allowing access to private members has a lot of implications, e.g. > breaks lots of optimizations b/c you can't know who accesses sth. It's > also yet unclear what effect this has on @safe and we'd not only have to > modify visibility but remove the access checks as well. This is clearly > too much to just fix that problem w/ certain template instantiations, > none of which should work on private members atm. > Also you'd have to change a lot of existing code, or it would now just > operate on private members. How is this supposed to work? What is the new guideline and who should bear the new guideline; the library author or the user? For this to work, the users must know that the library will call __traits(allMembers) so that they mixin and otherwise don't? That would be wrong in the other direction, no? The client needing to know about the library code? Wrong principle... What if I add a new private member to my otherwise public struct? Then I should remember to mixin all N templates that my module happens to be using right now? The only correct action that I see is that every template must be mixed-in in case I have a private member in the future or the library implementation may change in the future. I'm sorry but this is not usable. Ali P.S. While I'm on my soapbox, I've started to think private is overrated anyway. A system language should allow to bypass that protection. private should be a recommendation only.
Re: The D Language Foundation is now a tax exempt non-profit organization
On Monday, 29 August 2016 at 17:03:34 UTC, Andrei Alexandrescu wrote: We're happy to report that the D Language Foundation is now a public charity operating under US Internal Revenue Code Section 501(c)(3). The decision is retroactive to September 23, 2015. This has wide-ranging implications, the most important being that individuals and organizations may make tax deductible bequests, devises, transfers, or gifts to the Foundation. We will mull over defining donation and sponsorship packages in the near future. If interesting in donating spontaneously, feel free to reach out to us via email at foundat...@dlang.org. Many thanks are due to the folks in this community who asked for and supported this initiative. Fantastic! Congrats, nice work!
Re: Joakim Intreviews Walter for the D Blog
On Tuesday, 30 August 2016 at 19:44:19 UTC, Jacob Carlborg wrote: Some of the links have pretty long text, is that intended? Yes. Joakim submitted the text with the links already formatted and I left them in place.
Re: Beta D 2.071.2-b3
On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: As in needs private members in __traits(allMembers). and in the end it just producing excessive noise in common loops that does `is(typeof(__traits(getMember, ...)))`. it would be better to either leave that alone and allow all access, or exclude inaccessible members gin `allMembers` completely. yet D choose the third way, combining the worst features from both solutions.
Re: Beta D 2.071.2-b3
On Wednesday, 31 August 2016 at 05:23:34 UTC, ketmar wrote: On Tuesday, 30 August 2016 at 23:54:45 UTC, Martin Nowak wrote: As in needs private members in __traits(allMembers). and in the end it just producing excessive noise in common loops that does `is(typeof(__traits(getMember, ...)))`. it would be better to either leave that alone and allow all access, or exclude inaccessible members gin `allMembers` completely. yet D choose the third way, combining the worst features from both solutions. oops. seems that i did something wrong with myself. i'm sorry, the PR you linked seems to do exactly what i described. dunno how i managed to completely misunderstand it.
Re: Beta D 2.071.2-b3
On 2016-08-31 01:08, Martin Nowak wrote: Well there was reasoning to choose that solution instead of the other (https://github.com/dlang/dmd/pull/6078) and the fact that private members aren't accessible (set/get) is a good indication that nobody needs this. Class/struct fields are accessible using .tupleof. I was using __traits(getAttributes) in my serialization library to get UDA's for these fields, including private ones. -- /Jacob Carlborg
Re: Beta D 2.071.2-b3
On 2016-08-31 02:04, Ali Çehreli wrote: P.S. While I'm on my soapbox, I've started to think private is overrated anyway. A system language should allow to bypass that protection. private should be a recommendation only. I agree. Let private stop you from access symbols though the regular ways, but let reflection bypass. -- /Jacob Carlborg
Re: Beta D 2.071.2-b3
On 2016-08-31 01:08, Martin Nowak wrote: Well there was reasoning to choose that solution instead of the other (https://github.com/dlang/dmd/pull/6078) and the fact that private members aren't accessible (set/get) is a good indication that nobody needs this. Adding an unsafe facility to access private members is a separate problem, but please see the changelog for how to achieve this already by mixing in templates. In addition to using .tupleof to bypass protection it's possible to return a pointer to the symbol to bypass protection as well, fixing that would require some serious flow analysis. It's also possible to inspect the symbol table to access private symbols at runtime. -- /Jacob Carlborg
Re: Beta D 2.071.2-b3
On 2016-08-31 08:20, Jacob Carlborg wrote: Class/struct fields are accessible using .tupleof. I was using __traits(getAttributes) in my serialization library to get UDA's for these fields, including private ones. I think this was introduced already in 2.071.0. -- /Jacob Carlborg