On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer wrote:
> I'd say this deserves a blog post but it would be too short.

 Actually i wouldn't mind a vlog or some short presentations on a variety of subjects. Maybe even continuations of presentations that could have been at the Dlang conference except weren't due to time constraints.

On Tuesday, 6 June 2017 at 08:00:11 UTC, Era Scarecrow wrote:
> On Saturday, 3 June 2017 at 19:12:46 UTC, Steven Schveighoffer wrote:
>> I'd say this deserves a blog post but it would be too short.
>
>  Actually i wouldn't mind a vlog or some short presentations on a variety of subjects. Maybe even continuations of presentations that could have been at the Dlang conference except weren't due to time constraints.

I could post a video about a simple ctfe transcompiler.
or
sqlite-d.

I have to wait until my computer is fixed though.

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)

I think the allocation is because sort returns a SortedRange, not an array.

So even this allocates:

    enum b = a.sort;
    writeln(b[1]);

OTOH, this doesn't allocate:

    enum b = a.sort.array;
    writeln(b[1]);

On 6/6/17 8:28 PM, Yuxuan Shui 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)
>
> I think the allocation is because sort returns a SortedRange, not an array.
>
> So even this allocates:
>
>     enum b = a.sort;
>     writeln(b[1]);
>
> OTOH, this doesn't allocate:
>
>     enum b = a.sort.array;
>     writeln(b[1]);

I think it's because the compiler isn't smart enough to pull out the allocation for SortedRange!(...)([0,1,2,3,4])[1], but it is smart enough to know that [0,1,2,3,4][1] does not need to allocate.

But it is pretty well known that enum'ing an array can have it allocate wherever it is used.

For example, if you do this:

enum b = a.sort.array;
auto c = b;

It will allocate.

If you do:

auto d = b;

It will allocate again.

That is an interesting artifact though. Another good reason to use static.

-Steve

On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:

> But it is pretty well known that enum'ing an array can have it allocate
> wherever it is used.

One of the most effective examples is comparing .ptr with (seemingly) itself:

void main() {
    enum e = [ 1 ];
    static assert(e.ptr != e.ptr);
    assert(e.ptr != e.ptr);
}

Both asserts pass. I'm surprised that e.ptr is usable at compile time. Fine, I guess... :)

Ali

On 06/06/2017 08:06 PM, Ali Çehreli wrote:

>     enum e = [ 1 ];
>     static assert(e.ptr != e.ptr);
> I'm surprised that e.ptr is usable at compile time.

Sorry to notice this late but printing that ptr exposes the copy-paste behavior of enums:

    pragma(msg, e.ptr);

Outputs

&[1][0]

That makes sense. It's still interesting that static assert accepts that address comparison. I guess it knows that the result is always false.

Ali

On Wednesday, 7 June 2017 at 03:06:34 UTC, Ali Çehreli wrote:
> On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
>
> > But it is pretty well known that enum'ing an array can have
> it allocate
> > wherever it is used.
>
> One of the most effective examples is comparing .ptr with (seemingly) itself:
>
> void main() {
>     enum e = [ 1 ];
>     static assert(e.ptr != e.ptr);
>     assert(e.ptr != e.ptr);
> }
>
> Both asserts pass. I'm surprised that e.ptr is usable at compile time. Fine, I guess... :)
>
> Ali

A bit OT, but how about this one?

struct Tree {
    struct Node {
        Node* left, right;
    }

    Node* root = new Node;
}

void main() {
    Tree tree1, tree2;
    assert(tree1.root);
    assert(tree2.root);
    assert(tree1.root != tree2.root); // fails
}

Not `static`, not `enum`, but `new` at compile time and `root` is of course statically initialized :)

On 6/6/2017 8:06 PM, Ali Çehreli wrote:
> On 06/06/2017 06:09 PM, Steven Schveighoffer wrote:
> 
>  > But it is pretty well known that enum'ing an array can have it allocate
>  > wherever it is used.
> 
> One of the most effective examples is comparing .ptr with (seemingly) itself:
> 
> void main() {
>      enum e = [ 1 ];
>      static assert(e.ptr != e.ptr);
>      assert(e.ptr != e.ptr);
> }
> 
> Both asserts pass. I'm surprised that e.ptr is usable at compile time. Fine, I guess... :)

One trouble with making them the same is if one of the users of e changes an element. Do the rest of the users see the change or the original?