On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
> I would not have expected enum b = sort(a) to trigger an allocation. auto b, yes, of course (and the disassembly from that is not much different). So I'd love to see a blog post explaining it.

I don't think I can do a full-on blog post, but I can answer it in a couple sentences: `enum` is treated by the compiler just like literals. Array literals allocate at each usage point, therefore enum arrays allocate at each usage point. (*each* usage point)

On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
> On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
>> I would not have expected enum b = sort(a) to trigger an allocation. auto b, yes, of course (and the disassembly from that is not much different). So I'd love to see a blog post explaining it.
>
> I don't think I can do a full-on blog post, but I can answer it in a couple sentences: `enum` is treated by the compiler just like literals. Array literals allocate at each usage point, therefore enum arrays allocate at each usage point. (*each* usage point)

Right, but I was under the impression that was only for direct use of the enum literal:

enum a = [1, 2, 3];
auto b = a;

I thought that assigning the result of a function call to an enum would force a compile-time evaluation of the function, so I would expect enum b = call(lit) to be identical to static immutable b = call(lit).

On Sunday, 4 June 2017 at 04:47:56 UTC, Mike Parker wrote:
> On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:

>
> I thought that assigning the result of a function call to an enum would force a compile-time evaluation of the function, so I would expect enum b = call(lit) to be identical to static immutable b = call(lit).

Nevermind. I see where I got mixed up.

On Sunday, June 04, 2017 04:47:56 Mike Parker via Digitalmars-d wrote:
> On Sunday, 4 June 2017 at 04:39:21 UTC, Adam D. Ruppe wrote:
> > On Sunday, 4 June 2017 at 04:34:44 UTC, Mike Parker wrote:
> >> I would not have expected enum b = sort(a) to trigger an
> >> allocation. auto b, yes, of course (and the disassembly from
> >> that is not much different). So I'd love to see a blog post
> >> explaining it.
> >
> > I don't think I can do a full-on blog post, but I can answer it in a couple sentences: `enum` is treated by the compiler just like literals. Array literals allocate at each usage point, therefore enum arrays allocate at each usage point. (*each* usage point)
>
> Right, but I was under the impression that was only for direct use of the enum literal:
>
> enum a = [1, 2, 3];
> auto b = a;
>
> I thought that assigning the result of a function call to an enum would force a compile-time evaluation of the function, so I would expect enum b = call(lit) to be identical to static immutable b = call(lit).

As the enum has no address, it can't store anything. So, _anything_ that's an enum is going to be effectively copy-pasted everywhere that it's used. The compiler is smart enough to just copy-past the result and not the expression, but the result still must be copied, and in the case of a dynamic array, that means an allocation.

- Jonathan M Davis

On Sat, Jun 03, 2017 at 03:00:56PM -0700, Ali Çehreli via Digitalmars-d wrote:
> On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:
> 
> > I'd say this deserves a blog post but it would be too short.
> 
> I made many good friends at C++Now. Some of them know Atila from CppCon and other C++ conferences. (Beer involved. :) ) They told me Atila would routinely tell them during C++ presentations "This wouldn't be a talk at a DConf; it's a language feature in D." :)
[...]

In this case, I'd say "this wouldn't be an article about D; it's a language feature." :-D

Though I'd say we *could* add meat to the article by explaining what exactly CTFE is, how it works, and why you could just call the standard library sort at compile-time and have it Just Work(tm) without having to jump through hoops.

And perhaps demonstrate how easy it is to do this not just with sort, but with far more complex things.  In fact, significant chunks of Phobos are now available at CTFE.  For example, you can call std.format at compile-time to perform some pretty hairy string formatting and have the result baked into your executable so that you incur none of the cost of computing it at runtime.

The best part of all this is, as long as you have already written runtime code that's CTFE-compatible, you don't have to do anything else to make it work at compile-time. No messing around with constexpr, no awkward special syntax, no need to jump through hoops, invoke arcane black magic, etc.. Just call the code with normal runtime syntax from an expression whose value needs to be known at compile-time, and the compiler does the rest of you.

And if you need a particular functionality both at compile-time and during runtime, there's no need to write it twice in two different sublanguages. You just write one function once, and call it from both CTFE and at runtime. It Just Works(tm).

Then we could add the icing on the cake by showing off one of Andrei's(?) little gems in std.random: a RNG generator that checks *at compile-time* whether a particular set of RNG parameters would produce a poor-quality RNG, and abort with a compile-error if so.  Meaning that if the thing compiles at all, you have a minimum quality guarantee. (This particular gem is described in detail in TDPL, btw, and is one of the things about D that blew me away when I first read it.)


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.

On Sunday, 4 June 2017 at 05:12:13 UTC, Jonathan M Davis wrote:

> As the enum has no address, it can't store anything. So, _anything_ that's an enum is going to be effectively copy-pasted everywhere that it's used. The compiler is smart enough to just copy-past the result and not the expression, but the result still must be copied, and in the case of a dynamic array, that means an allocation.
>
> - Jonathan M Davis

Yeah, it hit me after my first reply to Adam. I'm in the middle of putting together a blog post right now.

On Sunday, 4 June 2017 at 05:38:24 UTC, H. S. Teoh wrote:

> And if you need a particular functionality both at compile-time and during runtime, there's no need to write it twice in two different sublanguages. You just write one function once, and call it from both CTFE and at runtime. It Just Works(tm).

...except when you have `if (__ctfe)` :P

On Sun, Jun 04, 2017 at 06:08:28AM +0000, Stanislav Blinov via Digitalmars-d wrote:
> On Sunday, 4 June 2017 at 05:38:24 UTC, H. S. Teoh wrote:
> 
> > And if you need a particular functionality both at compile-time and during runtime, there's no need to write it twice in two different sublanguages. You just write one function once, and call it from both CTFE and at runtime. It Just Works(tm).
> 
> ...except when you have `if (__ctfe)` :P

Ah, but if you want your function to work both at CTFE and runtime, then why write `if (__ctfe)` in the first place? :-D

Unless, of course, you're optimizing for runtime with something that's incompatible with CTFE, like inline assembly or something.  Then you're on your own. :-D


T

-- 
People say I'm indecisive, but I'm not sure about that. -- YHL, CONLANG

On Saturday, June 03, 2017 22:38:24 H. S. Teoh via Digitalmars-d wrote:
> On Sat, Jun 03, 2017 at 03:00:56PM -0700, Ali Çehreli via Digitalmars-d
wrote:
> > On 06/03/2017 12:12 PM, Steven Schveighoffer wrote:
> > > I'd say this deserves a blog post but it would be too short.
> >
> > I made many good friends at C++Now. Some of them know Atila from CppCon and other C++ conferences. (Beer involved. :) ) They told me Atila would routinely tell them during C++ presentations "This wouldn't be a talk at a DConf; it's a language feature in D." :)
>
> [...]
>
> In this case, I'd say "this wouldn't be an article about D; it's a language feature." :-D
>
> Though I'd say we *could* add meat to the article by explaining what exactly CTFE is, how it works, and why you could just call the standard library sort at compile-time and have it Just Work(tm) without having to jump through hoops.
>
> And perhaps demonstrate how easy it is to do this not just with sort, but with far more complex things.  In fact, significant chunks of Phobos are now available at CTFE.  For example, you can call std.format at compile-time to perform some pretty hairy string formatting and have the result baked into your executable so that you incur none of the cost of computing it at runtime.
>
> The best part of all this is, as long as you have already written runtime code that's CTFE-compatible, you don't have to do anything else to make it work at compile-time. No messing around with constexpr, no awkward special syntax, no need to jump through hoops, invoke arcane black magic, etc.. Just call the code with normal runtime syntax from an expression whose value needs to be known at compile-time, and the compiler does the rest of you.
>
> And if you need a particular functionality both at compile-time and during runtime, there's no need to write it twice in two different sublanguages. You just write one function once, and call it from both CTFE and at runtime. It Just Works(tm).
>
> Then we could add the icing on the cake by showing off one of Andrei's(?) little gems in std.random: a RNG generator that checks *at compile-time* whether a particular set of RNG parameters would produce a poor-quality RNG, and abort with a compile-error if so.  Meaning that if the thing compiles at all, you have a minimum quality guarantee. (This particular gem is described in detail in TDPL, btw, and is one of the things about D that blew me away when I first read it.)

Be careful, or Mike will start hounding you to write the actual article. ;)

- Jonathan M Davis

On Sunday, 4 June 2017 at 07:49:36 UTC, Jonathan M Davis wrote:

>
> Be careful, or Mike will start hounding you to write the actual article. ;)
>
> - Jonathan M Davis

It's already written! And I'm looking for reviewers [1] so I can get it in shape in time to publish Monday.

[1] http://forum.dlang.org/post/mosjryaaatmhqcpimmbs@forum.dlang.org