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.

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

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.

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.

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.

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.

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.