November 25, 2021

On Thursday, 25 November 2021 at 18:50:28 UTC, Teodor Dutu wrote:

>

On Thursday, 25 November 2021 at 16:16:11 UTC, Stanislav Blinov wrote:

>

What can be done then? If I understand correctly, the union approach was arrived at due to void initialization, as in case of exception array of garbage data is getting destructed. But then, couldn't one just write a T.init into the whole array if an exception is thrown, and not rely on a union at all?..

Actually, I used void initialisation because T.init couldn't be used when T is a nested struct, because of the context pointer, which is unavailable in the scope of _d_arrayctor.

I know, I was the one that suggested void initialization :D

>

On Thursday, 25 November 2021 at 16:16:11 UTC, Stanislav Blinov wrote:

> >
   foreach (ref it; result)
       emplaceInitializer(it); // this is nothrow

...pff, yeah, of course, and then we run into a segfault if it's an array of nested
structs, which was the problem "solved" with void initialization in the first place.
Not fun >:-E

I think you've already touched on what I said above, here. It's just that there wouldn't be a seg fault, but a compiler error, because of the aforementioned context pointer.

I'm just not expressing myself clearly :) This won't be a compile error. The emplaceInitializer above would plop a null context pointer into it, which, if the destructor actually accesses context, naturally would lead to a segfault in __ArrayDtor.

This can be avoided though, if you leech the context pointer from the elements of from when emplacing the initializer.

November 26, 2021

On Thursday, 25 November 2021 at 19:58:11 UTC, Stanislav Blinov wrote:

>

I'm just not expressing myself clearly :) This won't be a compile error. The emplaceInitializer above would plop a null context pointer into it, which, if the destructor actually accesses context, naturally would lead to a segfault in __ArrayDtor.

Note that this is exactly the current behavior of intimately-related .dup for non-POD slices: https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/object.d#L3601-L3627

November 26, 2021

On Friday, 26 November 2021 at 02:42:23 UTC, kinke wrote:

>

On Thursday, 25 November 2021 at 19:58:11 UTC, Stanislav Blinov wrote:

>

I'm just not expressing myself clearly :) This won't be a compile error. The emplaceInitializer above would plop a null context pointer into it, which, if the destructor actually accesses context, naturally would lead to a segfault in __ArrayDtor.

Note that this is exactly the current behavior of intimately-related .dup for non-POD slices: https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/object.d#L3601-L3627

https://issues.dlang.org/show_bug.cgi?id=22547

November 26, 2021

On Friday, 26 November 2021 at 11:59:37 UTC, Stanislav Blinov wrote:

>

On Friday, 26 November 2021 at 02:42:23 UTC, kinke wrote:

>

Note that this is exactly the current behavior of intimately-related .dup for non-POD slices: https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/object.d#L3601-L3627

https://issues.dlang.org/show_bug.cgi?id=22547

Thanks for filing. What I wanted to get at is that there seems to be a need for a copyEmplaceArray(S, T)(S[] source, T[] target), which can be used for _d_arrayctor, dup and copyEmplace (for static arrays). copyEmplace for static arrays currently handles throwing copies in yet another way (https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/core/lifetime.d#L1266-L1285), but that's already filed: https://issues.dlang.org/show_bug.cgi?id=22177

With copyEmplaceArray, _d_arrayctor could keep on stack-allocating the static array result and returning it via NRVO.

November 27, 2021

On Friday, 26 November 2021 at 14:58:04 UTC, kinke wrote:

>

On Friday, 26 November 2021 at 11:59:37 UTC, Stanislav Blinov wrote:

>

On Friday, 26 November 2021 at 02:42:23 UTC, kinke wrote:

>

Note that this is exactly the current behavior of intimately-related .dup for non-POD slices: https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/object.d#L3601-L3627

https://issues.dlang.org/show_bug.cgi?id=22547

Thanks for filing. What I wanted to get at is that there seems to be a need for a copyEmplaceArray(S, T)(S[] source, T[] target), which can be used for _d_arrayctor, dup and copyEmplace (for static arrays). copyEmplace for static arrays currently handles throwing copies in yet another way (https://github.com/dlang/druntime/blob/595707b1ac8a439b2a7243b0abf95d4bc56239ff/src/core/lifetime.d#L1266-L1285), but that's already filed: https://issues.dlang.org/show_bug.cgi?id=22177

With copyEmplaceArray, _d_arrayctor could keep on stack-allocating the static array result and returning it via NRVO.

I've left some thoughts on that in the bug tracker.

As for making a generic utility - absolutely agree. However, it does require an upgrade for copyEmplace - it has to be made to work in CTFE, which it currently doesn't due to the way it blits. If _d_arrayctor is to be made a lowering for array initialization, and involve copyEmplace, we need it to work at compile time. .dup can (and does) work around it trivially, but _d_arrayctor wouldn't be able to.

1 2
Next ›   Last »