As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all.

A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors.

Thanks in advance.

[1] http://forum.dlang.org/post/bhdehyzrlfklfkxicpea@forum.dlang.org
[2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3

On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:

> I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors.

> https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3

Added a couple of comments.

On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:
> As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all.
>
> A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors.
>
> Thanks in advance.
>
> [1] http://forum.dlang.org/post/bhdehyzrlfklfkxicpea@forum.dlang.org
> [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3

I don't think this is a good response to the original post, diving into a bunch of arcana about initialization and allocation rather than showing how simple D's compile-time sort is.  It'd be better to just have a nuts and bolts post showing how the _same_ code can be done much easier in D, including actually showing D's quicksort and maybe mentioning __ctfe, then show how easy it is to do something much more advanced in D, like Teoh said.  This post goes off on a couple tangents, maybe it could be a follow-up blog post after one addressing the original C++ post.

On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:
> I've slapped together a blog post about it all.
>
>

So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here:

https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453

I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it).

Destroy!

On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:
> On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:
>> I've slapped together a blog post about it all.
>>
>>
>
> So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here:
>
> https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453
>
> I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it).
>
> Destroy!

Much better, a standard overview of CTFE, but that's better for a general audience.  I'd leave out the bit about allocation altogether, a technical detail that depends on the compiler and could just be fixed someday.  Stick that in your GC blog post later on, and refer back to this post then.

On Sunday, 4 June 2017 at 16:48:11 UTC, Joakim wrote:
> On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:
>> [...]
>
> Much better, a standard overview of CTFE, but that's better for a general audience.  I'd leave out the bit about allocation altogether, a technical detail that depends on the compiler and could just be fixed someday.  Stick that in your GC blog post later on, and refer back to this post then.

Oh, I'd actually show the source for our quicksort too, to emphasize how different it is from theirs.

On 06/04/2017 06:07 PM, Mike Parker wrote:
> https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453

From there: "What it boils down to is this: if a function *can* be executed at compile time, it *will* be."

I think that gives the wrong impression. We regularly have newcomers in D.learn who expect CTFE to happen where it doesn't. They have a function call with all compile-time constants, and they expect it to be handled by CTFE. They think that the call *can* be evaluated at compile time, so it *will* be. But that's not how it works. CTFE only kicks in when the destination *requires* a compile-time constant.

On Sunday, June 04, 2017 19:16:09 ag0aep6g via Digitalmars-d wrote:
> On 06/04/2017 06:07 PM, Mike Parker wrote:
> > https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453
>
>  From there: "What it boils down to is this: if a function *can* be
> executed at compile time, it *will* be."
>
> I think that gives the wrong impression. We regularly have newcomers in D.learn who expect CTFE to happen where it doesn't. They have a function call with all compile-time constants, and they expect it to be handled by CTFE. They think that the call *can* be evaluated at compile time, so it *will* be. But that's not how it works. CTFE only kicks in when the destination *requires* a compile-time constant.

Yeah, the compiler doesn't care at all about whether a function can be called during CTFE until it actually attempts it, and it's only going to attempt it in a context where the result _must_ be known at compile-time, whereas that line implies that the compiler calls functions at compile-time whenever it can, which would have a _very_ different effect.

- Jonathan M Davis

On Sunday, 4 June 2017 at 08:34:23 UTC, Mike Parker wrote:
> As a result of the ongoing thread, 'C++17 cannot beat D surely' [1], I've slapped together a blog post about it all.
>
> A post about CTFE sort in D by itself would be rather short. So I also wrote about two points of the confusion (one of which was my own) that arose in the thread. I'd like to publish it tomorrow (Monday), so I've put the draft in a gist [2] and I'm looking to get anyone who's willing to read it and let me know here if I've made any errors.
>
> Thanks in advance.
>
> [1] http://forum.dlang.org/post/bhdehyzrlfklfkxicpea@forum.dlang.org
> [2] https://gist.github.com/mdparker/c674888dea1e0ead0c6a8fd28b0333d3


Just a minor typo: writeln(b); should be // [1, 2, 3]

   enum int[] a = [ 3, 1, 2 ];
   static b = sort(a);
   writeln(b); // [0, 1, 2, 3, 4]

On Sunday, 4 June 2017 at 16:07:35 UTC, Mike Parker wrote:

> So I took the feedback I've gotten so far, stepped away and thought about it for a bit, and agreed that I was taking the wrong approach. So I've given it a rewrite. The original gist is still there, but the new one is here:
>
> https://gist.github.com/mdparker/51599471b5f19fe05ff01ca95b34d453
>
> I'm open to any changes or additions anyone would like to make. That includes rewriting large portions of it (or all of it, if anyone is up for it).
>
> Destroy!

Thanks to everyone who provided feedback here and elsewhere. I've incorporated much of it and that has resulted in a much better post. I'll be publishing it in a ~ 3 hours or so.