C++17 cannot beat D surely

[Jonathan M Davis via Digitalmars-d]

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