Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 18/05/18 22:57, kinke wrote: I checked, and the reason is that D and C++ use a different ABI wrt. by-value passing of non-POD arguments. C++ indeed passes a reference to a caller-allocated rvalue, not just on Win64; that makes it trivial, as there are no moves across call boundaries. But

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 19:11:27 UTC, Shachar Shemesh wrote: On 17/05/18 18:47, kinke wrote: Since clang is able to compile this struct and do everything with it, and since the existence of the move constructor requires the precise same type of hooking as is needed in this case, I tend to

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 20:25:26 UTC, Shachar Shemesh wrote: Obviously, Something can be an enum or a boolean. If it is, however, then we have to perform a condition to select the correct value. The problem with conditionals is that if the CPU misses a guess about what they are (and in our

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 19:13:48 UTC, Shachar Shemesh wrote: The only inherent non @safe thing we advocate here is if you want to be able to move const/immutable structs, in which case DIP 1014 advocates casting the constness away. That will, of course, have to be either @system or

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17 May 2018 at 13:25, Shachar Shemesh via Digitalmars-d wrote: > On 17/05/18 22:29, Manu wrote: >> >> >> This is great! >> I've wanted this on numerous occasions when interacting with C++ code. >> This will make interaction more complete. >> >> Within

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17/05/18 22:29, Manu wrote: This is great! I've wanted this on numerous occasions when interacting with C++ code. This will make interaction more complete. Within self-contained D code, I have avoided self-pointers by using self-offsets instead in the past (a bit hack-ey). But this nicely

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17 May 2018 at 01:12, Mike Parker via Digitalmars-d wrote: > This is the review thread for the first Community Review round for DIP 1014, > "Hooking D's struct move semantics". > > All review-related feedback on and discussion of the DIP should occur in > this

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17/05/18 19:08, Kagamin wrote: On Thursday, 17 May 2018 at 13:50:26 UTC, Shachar Shemesh wrote: There is no such use case. Please remember that at the time opPostMove is called, both new and old memory are still allocated. That's an interesting moment too. A struct that was supposed to be

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17/05/18 18:47, kinke wrote: On Thursday, 17 May 2018 at 15:23:50 UTC, kinke wrote: See IR for https://run.dlang.io/is/1JIsk7. I should probably emphasize that the LLVM `byval` attribute is strange at first sight. Pseudo-IR `void foo(S* byval param); ... foo(S* byarg arg);` doesn't mean

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 13:50:26 UTC, Shachar Shemesh wrote: There is no such use case. Please remember that at the time opPostMove is called, both new and old memory are still allocated. That's an interesting moment too. A struct that was supposed to be moved is copied instead and

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 15:23:50 UTC, kinke wrote: See IR for https://run.dlang.io/is/1JIsk7. I should probably emphasize that the LLVM `byval` attribute is strange at first sight. Pseudo-IR `void foo(S* byval param); ... foo(S* byarg arg);` doesn't mean that the IR callee gets the S*

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 12:36:29 UTC, Shachar Shemesh wrote: Again, as far as I know, structs are not copied when passed as arguments. They are allocated on the caller's stack and a reference is passed to the callee. If that's the case, no move (of any kind) is done. That's the exception

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17/05/18 16:42, Kagamin wrote: Looks like requirement for @nogc @safe has no consequence as the DIP suggests to infer them anyway. On ideological side safety can't be a requirement because it would contradict its purpose of providing guarantee. I think you are confusing __move_post_blt's

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

Looks like requirement for @nogc @safe has no consequence as the DIP suggests to infer them anyway. On ideological side safety can't be a requirement because it would contradict its purpose of providing guarantee. Especially if the suggested use case is handling of dangling pointers.

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

I'm not sure I follow all of your comments. For the rest my comments, let's assume that the compiler may assume that __move_post_blt is a no-op if hasElaborateMove returns false. On 17/05/18 14:33, kinke wrote: 3. When deciding to move a struct instance, the compiler MUST emit a call to the

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

3. When deciding to move a struct instance, the compiler MUST emit a call to the struct's __move_post_blt after blitting the instance and before releasing the memory containing the old instance. __move_post_blt MUST receive references to both the pre- and post-move instances. This implies

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17/05/18 11:22, rikki cattermole wrote: What is the benefit of opPostMove over copy constructors (not postblit)? The two are unrelated. A copy is a very different operation from a move. With a copy, you have to figure out how to duplicate the resources used by the object. With a move, no

Re: DIP 1014: Hooking D's struct move semantics -- Community Review Round 1 Begins

On 17/05/2018 8:15 PM, Mike Parker wrote: The first round of Community Review for DIP 1014, "Hooking D's struct move semantics", has begun. To participate, please visit the review thread for the details and leave all feedback there rather than here:

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On 17/05/2018 8:12 PM, Mike Parker wrote: This is the review thread for the first Community Review round for DIP 1014, "Hooking D's struct move semantics". All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on May

DIP 1014: Hooking D's struct move semantics -- Community Review Round 1 Begins

The first round of Community Review for DIP 1014, "Hooking D's struct move semantics", has begun. To participate, please visit the review thread for the details and leave all feedback there rather than here: https://forum.dlang.org/post/zfyfhqczkrfdpfkca...@forum.dlang.org

DIP 1014:Hooking D's struct move semantics--Community Review Round 1

This is the review thread for the first Community Review round for DIP 1014, "Hooking D's struct move semantics". All review-related feedback on and discussion of the DIP should occur in this thread. The review period will end at 11:59 PM ET on May 31, or when I make a post declaring it

Re: DIP 1014:Hooking D's struct move semantics--Community Review Round 1

On Thursday, 17 May 2018 at 08:12:50 UTC, Mike Parker wrote: This is the review thread for the first Community Review round for DIP 1014, "Hooking D's struct move semantics". And the link to the DIP: https://github.com/dlang/DIPs/blob/38cec74a7471735559e3b8a7553f55102d289d28/DIPs/DIP1014.md