On Thursday, 19 March 2020 at 18:41:07 UTC, Jacob Carlborg wrote:
> On 2020-03-19 11:17, Mathias Lang wrote:
>
>> but as often, the solution is to turn a runtime parameter into a compile time one and to add another level of indirection.
>
> If you don't use static initialization and instead assign the fields one by one it should work without the indirection.

But you can't deal with user-provided types. You'll have to blindly cast away to mutable to make it work. And from my experience, ignoring the type system always comes back to bite you at one point or another.

On Thursday, 19 March 2020 at 17:57:46 UTC, kinke wrote:
>
> Yeah, I'd suggest not to look at how this is currently implemented (Walter doesn't seem to see the advantage of a move compiler intrinsic). With a proper optimizer, you shouldn't have to care (see LDC result).
> Wrt. interior pointers, that's in the spec and could bite you in different places where moving is implicit.
>
>> I also found out that one of the earlier case I mentioned (https://gist.github.com/Geod24/61ef0d8c57c3916cd3dd7611eac8234e#file-nrvo_struct_ctor-d) only does NRVO on LDC. DMD (and GDC 9.3.0) just silently move it.
>
> I've been working on improving things in this regard, especially with v1.19.

Thanks a lot for that. I started to add some NRVO tests to our CI, and had to disable them for DMD. We're developing on Mac OSX and I've been debating for a while whether we should drop DMD or not, because it's just too much effort for us to maintain compatibility for it.

The interior pointer thing I was aware of, but upon searching the spec, I can't find anything about it. There is a mention of moving garbage collection, but that should only be valid for object that belongs to the GC. And event if there was a moving garbage collector, I doubt we could use it with C++ object. "move construction dlang" and "interior pointer dlang" both yield a few interesting discussion, but nothing in the spec (No hit on "move"  in https://dlang.org/spec/struct.html).

And from what I remember, the "no interior pointer" rule was mostly there to prevent us from entering the same complexity as C++ when it comes to copy / move constructors. However that position is not really tenable if we want to properly interface with C++.

For reference, the tests I added are here (https://github.com/Geod24/agora/blob/e765b5b53453c928a7488ea616e90bcd1b93b5b2/source/agora/test/NRVO.d) and the actual serializer implementation is here (https://github.com/Geod24/agora/blob/e765b5b53453c928a7488ea616e90bcd1b93b5b2/source/agora/common/Serializer.d). At this point, I'm considering just writing a template that transforms a type to another one with a specific field wrapped with one of those NRVO-checking struct, so I can systematically detect any place where a move is performed instead of NRVO in the serializer code.

On Friday, 20 March 2020 at 13:32:24 UTC, Mathias Lang wrote:
> The interior pointer thing I was aware of, but upon searching the spec, I can't find anything about it. [...] https://dlang.org/spec/struct.html

It's point 2, 'a struct is defined to not have an identity; that is, the implementation is free to make bit copies of the struct as convenient'. I thought it'd clearly say something about interior pointers; maybe that was removed as anticipation for opPostMove / move constructors, which would permit interior pointers (with manual updating after a move).

On 2020-03-20 13:27, Mathias Lang wrote:

> But you can't deal with user-provided types. You'll have to blindly cast away to mutable to make it work. 

Yes.

> And from my experience, ignoring the type system always comes back to bite you at one point or another.

Possibly, but I think in this case it's fine.

Static initialization cannot be used if the struct has a constructor defined.

In my serialization library, Orange [1], I'm both casting away immutable/const and bypass any constructors.

[1] https://github.com/jacob-carlborg/orange

-- 
/Jacob Carlborg

On Thursday, 19 March 2020 at 17:38:42 UTC, Mathias Lang wrote:
>
> I also found out that one of the earlier case I mentioned (https://gist.github.com/Geod24/61ef0d8c57c3916cd3dd7611eac8234e#file-nrvo_struct_ctor-d) only does NRVO on LDC. DMD (and GDC 9.3.0) just silently move it.

Looking at the code-gen, it seems like it's doing NRVO to me.  Didn't look at the assembly though.