www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - More incremental process for adding new features in D

reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
After having read incremental progress on language constructs 
supported in `const fn` in Rust version 1.46 at

https://blog.rust-lang.org/2020/08/27/Rust-1.46.0.html#const-fn-improvements

C++ has taken a similar approach when adding support for more 
language constructs that can be used in `consteval` functions.

I wonder why we haven't taken an incremental approach to newCTFE 
aswell. I bet there are numerous projects who could benefit from 
it despite its lack of associative arrays and exception handling.

Adding newCTFE as a -preview=new-ctfe will gather feedback on 
bugs and performance and will motivate the developers themselves 
in helping Stefan out in making newCTFE more complete.
Sep 02 2020
parent reply Seb <seb wilzba.ch> writes:
On Wednesday, 2 September 2020 at 19:45:58 UTC, Per Nordlöw wrote:
 I wonder why we haven't taken an incremental approach to 
 newCTFE aswell. I bet there are numerous projects who could 
 benefit from it despite its lack of associative arrays and 
 exception handling.
IIRC newCTFE was never in a mergeable state (i.e. not based against master). In general, the barrier for new features is rather low when they are introduced via a `-preview` switch (that's exactly why this switch was introduced) and such experimental features don't require a DIP or full completeness of every corner case. The PR does need to match with the usual guidelines (D style, new code covered by tests). The problem typically is that a -preview flag might break existing code and there isn't a straight-forward transition via deprecations which is why features under -preview have a harder time to get activated by default. That being said, for example, DDoc's markdown support was added incrementally to -preview=markdown: https://github.com/dlang/dmd/pulls?q=is%3Apr+markdown+author%3Adgileadi and will even be activated by default with the upcoming release.
 Adding newCTFE as a -preview=new-ctfe will gather feedback on 
 bugs and performance and will motivate the developers 
 themselves in helping Stefan out in making newCTFE more 
 complete.
Didn't Stefan give up on newCTFE? https://forum.dlang.org/post/fyakhpjbcpzqegfevxwg forum.dlang.org
Sep 02 2020
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Thursday, 3 September 2020 at 05:27:44 UTC, Seb wrote:
 That being said, for example, DDoc's markdown support was added 
 incrementally to -preview=markdown:

 https://github.com/dlang/dmd/pulls?q=is%3Apr+markdown+author%3Adgileadi

 and will even be activated by default with the upcoming release.
Nice. Thanks.
 Didn't Stefan give up on newCTFE?

 https://forum.dlang.org/post/fyakhpjbcpzqegfevxwg forum.dlang.org
I thought somebody could take over and have it merged bit by bit behind a `-preview` flag. I guess we need some more benchmarks of what's taking time. And perhaps let Stefan's works on alias functions get accepted and merged behind a -preview flag.
Sep 03 2020
prev sibling parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Thursday, 3 September 2020 at 05:27:44 UTC, Seb wrote:
 Didn't Stefan give up on newCTFE?

 https://forum.dlang.org/post/fyakhpjbcpzqegfevxwg forum.dlang.org
I sure hope he hasn't. It looks like he is very close to finishing it and giving up now would be a terrible waste.
Sep 03 2020
next sibling parent Bruce Carneal <bcarneal gmail.com> writes:
On Thursday, 3 September 2020 at 09:50:02 UTC, Sebastiaan Koppe 
wrote:
 On Thursday, 3 September 2020 at 05:27:44 UTC, Seb wrote:
 Didn't Stefan give up on newCTFE?

 https://forum.dlang.org/post/fyakhpjbcpzqegfevxwg forum.dlang.org
I sure hope he hasn't. It looks like he is very close to finishing it and giving up now would be a terrible waste.
Well, if it's now clear that there is a better path to improve the CT experience I'd expect Stefan to take it. As indicated in the post linked to there may be "bigger fish to fry". While nobody likes to see a lot of effort set aside, at the least it looks like we're gaining a better understanding of what matters at CT.
Sep 03 2020
prev sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Thursday, 3 September 2020 at 09:50:02 UTC, Sebastiaan Koppe 
wrote:
 On Thursday, 3 September 2020 at 05:27:44 UTC, Seb wrote:
 Didn't Stefan give up on newCTFE?

 https://forum.dlang.org/post/fyakhpjbcpzqegfevxwg forum.dlang.org
I sure hope he hasn't. It looks like he is very close to finishing it and giving up now would be a terrible waste.
Sunken cost fallacy. The complexity newCTFE would add to the compiler isn't worth the little benefit it would add. Yes it'd be a waste, but that shouldn't be the reason it gets incorporated, just so that it wouldn't be a waste.
Sep 03 2020
parent Sebastiaan Koppe <mail skoppe.eu> writes:
On Thursday, 3 September 2020 at 15:51:52 UTC, Avrina wrote:
 On Thursday, 3 September 2020 at 09:50:02 UTC, Sebastiaan Koppe 
 wrote:
 I sure hope he hasn't. It looks like he is very close to 
 finishing it and giving up now would be a terrible waste.
Sunken cost fallacy. The complexity newCTFE would add to the compiler isn't worth the little benefit it would add. Yes it'd be a waste, but that shouldn't be the reason it gets incorporated, just so that it wouldn't be a waste.
I was talking about seeing something through till the end and finishing what you started. Sure, if endeavours turn out to be losers, drop them quickly, I just don't think that is the case here.
Sep 08 2020