Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted

On Thursday, 8 November 2018 at 03:04:06 UTC, Jonathan M Davis wrote: On Wednesday, November 7, 2018 6:54:54 PM MST Mike Parker via Digitalmars-d- announce wrote: I'm happy to announce that Walter and Andrei have rendered their verdict on DIP 1014. They were in agreement on two points: they

Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted

On Thursday, 8 November 2018 at 02:36:21 UTC, test wrote: Thanks to all for the hard work. Look forward DIP1016 to be approved. Agreed!

Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted

On Wednesday, November 7, 2018 6:54:54 PM MST Mike Parker via Digitalmars-d- announce wrote: > I'm happy to announce that Walter and Andrei have rendered their > verdict on DIP 1014. They were in agreement on two points: they > don't like it, but they know we need it. Given that there are no >

Re: DIP 1014--Hooking D's struct move semantics--Has Been Accepted

On Thursday, 8 November 2018 at 01:54:54 UTC, Mike Parker wrote: I'm happy to announce that Walter and Andrei have rendered their verdict on DIP 1014. They were in agreement on two points: they don't like it, but they know we need it. Given that there are no other alternative proposals and

Re: DIP 1014

On Thursday, 4 October 2018 at 12:08:38 UTC, Shachar Shemesh wrote: Two distinct things. Kinke was talking about how to pass a struct through the ABI. You are talking about special-casing a specific name. Not just name, but argument passing as well. Not to mention, your special case is to

Re: DIP 1014

On 04/10/18 13:43, Stanislav Blinov wrote: * move the data as part of the call hook rather than before * Use a different name and signature on the hook function Yes, exactly. It would have to be special if you don't want to leave room for the compiler implementors. That's not how

Re: DIP 1014

On Thursday, 4 October 2018 at 08:32:44 UTC, Shachar Shemesh wrote: On 04/10/18 11:16, Paolo Invernizzi wrote: While I want to thank you both, about the quality of this thread, what kind of "consequences that go beyond what I think you understand" are you thinking of? Can you give an example?

Re: DIP 1014

On 04/10/18 11:16, Paolo Invernizzi wrote: While I want to thank you both, about the quality of this thread, what kind of "consequences that go beyond what I think you understand" are you thinking of? Can you give an example? Assuming I understand Stanislav's proposal correctly (an assumption

Re: DIP 1014

On Thursday, 4 October 2018 at 08:10:31 UTC, Shachar Shemesh wrote: On 04/10/18 11:05, Stanislav Blinov wrote: On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote: [...] For the love of Pete, that program was an example of how a move hook should work, *not* a demonstration

Re: DIP 1014

On 04/10/18 11:05, Stanislav Blinov wrote: On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote: If you do *anything* to that program, and that includes even changing its compilation flags (try enabling inlining), it will stop working. You should have known that when you found

Re: DIP 1014

On Thursday, 4 October 2018 at 03:06:35 UTC, Shachar Shemesh wrote: If you do *anything* to that program, and that includes even changing its compilation flags (try enabling inlining), it will stop working. You should have known that when you found out it doesn't work on ldc: ldc and dmd

Re: DIP 1014

On Wed, Oct 3, 2018 at 11:00 PM Timothee Cour via Digitalmars-d wrote: > > @Manu, @Jonathan M Davis > > > GNU's std::string implementation stores an interior pointer! >_< > > it's not just GNU's std::string ; it can crop up in other places, see > https://github.com/Syniurge/Calypso/issues/70 in

Re: DIP 1014

@Manu, @Jonathan M Davis > GNU's std::string implementation stores an interior pointer! >_< it's not just GNU's std::string ; it can crop up in other places, see https://github.com/Syniurge/Calypso/issues/70 in opencv (cv:: MatStep) On Wed, Oct 3, 2018 at 8:10 PM Shachar Shemesh via

Re: DIP 1014

On 03/10/18 23:25, Stanislav Blinov wrote: It *is* true when the type doesn't have a destructor. Extending that to a move hook, it will also be true because destruction will be elided. I know what you're talking about, that happens for types that have destructors. No, destructors have nothing

Re: DIP 1014

On Wednesday, 3 October 2018 at 18:58:37 UTC, Shachar Shemesh wrote: On 03/10/18 20:43, Stanislav Blinov wrote: On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote: I.e. - I am asserting if a move was not caught. The program fails to run on either ldc or dmd. To me, this

Re: DIP 1014

On Wednesday, 3 October 2018 at 18:38:50 UTC, Manu wrote: On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via Digitalmars-d wrote: Any function in D that has a signature of the form ReturnType foo(Type x); in C++ would have an equivalent signature of ReturnType foo(Type&& x); // NOT

Re: DIP 1014

On 03/10/18 20:43, Stanislav Blinov wrote: On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote: I.e. - I am asserting if a move was not caught. The program fails to run on either ldc or dmd. To me, this makes perfect sense as for the way D is built. In essence, opAssign

Re: DIP 1014

On Wed, Oct 3, 2018 at 7:00 AM Stanislav Blinov via Digitalmars-d wrote: > > Shachar, as I don't see a better place of discussing that DIP at > the moment, I'll pour some observations and thoughts in here if > you don't mind, will add some comments on GitHub later. > As I see it right now, it's a

Re: DIP 1014

On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: Okay, so copy elision is working... but moves otherwise are not? That's still not what we've been peddling all these years. A whole lot of design surface area is dedicated to implicit move semantics... and they don't work? What does it

Re: DIP 1014

On Wednesday, 3 October 2018 at 17:43:08 UTC, Stanislav Blinov wrote: But IMHO, it's something that should be fixed by not making these facilities built into the language. s/not//

Re: DIP 1014

On Wednesday, 3 October 2018 at 15:33:00 UTC, Shachar Shemesh wrote: On 03/10/18 17:29, Stanislav Blinov wrote: OMG, that's so simple!!! Why didn't I think of it? Oh wait, I did. Now I see why sometimes your posts are greeted with hostility. Yes. I am actually sorry about that. I was

Re: DIP 1014

On 03/10/18 12:48, Corel wrote: The fact that in D the structures to date are not moved, is known for years ... take advantage of this fact, and move on. I have no idea where you got this fact: import std.stdio; struct MoveTest { static uint counter=1; uint id; @disable

Re: DIP 1014

On Wed, Oct 3, 2018 at 2:50 AM Corel via Digitalmars-d wrote: > > On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: > > On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d > > wrote: > >> > >> On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > >> > On Tuesday, 2 October 2018 at

Re: DIP 1014

On 03/10/18 18:33, Shachar Shemesh wrote: ~this() {     writefln("%s destructed", );     assert(counter is null || counter is );     } You might also want to add @disable this(this); and remove the dead code (i.e. - the case where the pointer is global) to reduce noise. I

Re: DIP 1014

On 03/10/18 17:29, Stanislav Blinov wrote: OMG, that's so simple!!! Why didn't I think of it? Oh wait, I did. Now I see why sometimes your posts are greeted with hostility. Yes. I am actually sorry about that. I was responding to your assumption that I'm wrong. Had your post been phrased

Re: DIP 1014

On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh wrote: If you read the DIP, you will notice that the *address* in which the old instance resides is quite important... Allow me to further illustrate with something that can be written in D today: import std.stdio; struct

Re: DIP 1014

On Wednesday, 3 October 2018 at 14:07:58 UTC, Shachar Shemesh wrote: On 03/10/18 16:56, Stanislav Blinov wrote: struct S {     this(S rhs); OMG, that's so simple!!! Why didn't I think of it? Oh wait, I did. Now I see why sometimes your posts are greeted with hostility. And this simply

Re: DIP 1014

On 03/10/18 16:56, Stanislav Blinov wrote: struct S {     this(S rhs); OMG, that's so simple!!! Why didn't I think of it? Oh wait, I did. And this simply and utterly doesn't work. If you read the DIP, you will notice that the *address* in which the old instance resides is quite important

Re: DIP 1014

On Wednesday, 3 October 2018 at 13:56:29 UTC, Stanislav Blinov wrote: Aendment, this should of course be: this(Tracker oldLocation) { localCounter = oldLocation.locaclCounter; counter = oldLocation.counter; if( counter is ) counter = }

Re: DIP 1014

Shachar, as I don't see a better place of discussing that DIP at the moment, I'll pour some observations and thoughts in here if you don't mind, will add some comments on GitHub later. As I see it right now, it's a case of over-engineering of a quite simple concept. 1. A new function, called

Re: DIP 1014

On 03/10/18 04:10, Walter Bright wrote: On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote: Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved structs in a number of situations - e.g. when the return value was an

Re: DIP 1014

On Wednesday, 3 October 2018 at 08:21:38 UTC, Manu wrote: On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d wrote: On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis > wrote: >> Yeah. IIRC, it was supposed to be _guaranteed_

Re: DIP 1014

On Tue, Oct 2, 2018 at 6:15 PM Walter Bright via Digitalmars-d wrote: > > On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: > > On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote: > >> Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved > >> structs > >> in a number

Re: DIP 1014

On 10/2/2018 4:30 PM, Adam D. Ruppe wrote: On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote: Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved structs in a number of situations - e.g. when the return value was an rvalue. Something like Eh, I don't think

Re: DIP 1014

On Tuesday, 2 October 2018 at 22:30:38 UTC, Jonathan M Davis wrote: Yeah. IIRC, it was supposed to be _guaranteed_ that the compiler moved structs in a number of situations - e.g. when the return value was an rvalue. Something like Eh, I don't think that moves it, but rather just constructs

Re: DIP 1014

On Tuesday, October 2, 2018 11:54:57 AM MDT Manu via Digitalmars-d wrote: > On Tue, Oct 2, 2018 at 2:40 AM Walter Bright via Digitalmars-d > > wrote: > > On 10/2/2018 2:17 AM, Walter Bright wrote: > > > 1. Don't allow moving of C++ structs > > > 2. Add a struct attribute that means "not moveable"

Re: DIP 1014

On 10/2/18 1:51 PM, Manu wrote: But dangling pointer is an instant crash/memory corruption... it's a pretty bad 'bug'. Yeah doesn't sound very brilliant. I think such a workaround wouldn't fare well. To keep momentum while we mull over a solution to this I suggest you look at porting other

Re: DIP 1014

On Tue, Oct 2, 2018 at 2:40 AM Walter Bright via Digitalmars-d wrote: > > On 10/2/2018 2:17 AM, Walter Bright wrote: > > 1. Don't allow moving of C++ structs > > 2. Add a struct attribute that means "not moveable" > > 3. DIP 1014, which is add a __move_post_blit() function (most complex > >

Re: DIP 1014

On Tue, Oct 2, 2018 at 2:20 AM Walter Bright via Digitalmars-d wrote: > > On 9/29/2018 9:34 PM, Manu wrote: > > Who knows about DIP 1014? (struct move hook) > > Is it well received? Is it likely to be accepted soon? > > > > I'm working on the std::string binding, it's almost finished... but > >

Re: DIP 1014

On 10/2/2018 2:17 AM, Walter Bright wrote: 1. Don't allow moving of C++ structs 2. Add a struct attribute that means "not moveable" 3. DIP 1014, which is add a __move_post_blit() function (most complex solution) 4. Use copy/destruct for C++ structs that have copy constructors (this is the old

Re: DIP 1014

On 9/29/2018 9:34 PM, Manu wrote: Who knows about DIP 1014? (struct move hook) Is it well received? Is it likely to be accepted soon? I'm working on the std::string binding, it's almost finished... but then I hit a brick wall. GNU's std::string implementation stores an interior pointer! >_<

Re: DIP 1014

On 9/29/2018 9:34 PM, Manu wrote: Who knows about DIP 1014? (struct move hook) When discussing DIP 1014, a link is helpful: https://github.com/dlang/DIPs/blob/38cec74a7471735559e3b8a7553f55102d289d28/DIPs/DIP1014.md

Re: DIP 1014

On Sunday, September 30, 2018 1:35:28 AM MDT Shachar Shemesh via Digitalmars-d wrote: > On 30/09/18 10:26, Manu wrote: > > Other implementations make much better use of that built-in space by > > not wasting 8 bytes on an interior pointer for small-strings. > > I will point out that a pointer

Re: DIP 1014

On 30/09/18 10:26, Manu wrote: Other implementations make much better use of that built-in space by not wasting 8 bytes on an interior pointer for small-strings. I will point out that a pointer that *sometimes* points to an internal member was one of the use cases I documented when I

Re: DIP 1014

On Sat, Sep 29, 2018 at 11:50 PM Walter Bright via Digitalmars-d wrote: > > On 9/29/2018 9:34 PM, Manu wrote: > > GNU's std::string implementation stores an interior pointer! >_< > > > > No other implementation does this. It's a really bad implementation > > actually, quite inefficient. It could

Re: DIP 1014

On 9/29/2018 9:34 PM, Manu wrote: GNU's std::string implementation stores an interior pointer! >_< No other implementation does this. It's a really bad implementation actually, quite inefficient. It could make better use of its space for small-strings if it wasn't wasting 8-bytes for an

Re: DIP 1014

On Saturday, September 29, 2018 10:34:20 PM MDT Manu via Digitalmars-d wrote: > Who knows about DIP 1014? (struct move hook) > Is it well received? Is it likely to be accepted soon? > > I'm working on the std::string binding, it's almost finished... but > then I hit a brick wall. > GNU's

Re: DIP 1014

On Sunday, 30 September 2018 at 04:34:20 UTC, Manu wrote: Who knows about DIP 1014? (struct move hook) Is it well received? Is it likely to be accepted soon? I'm working on the std::string binding, it's almost finished... but then I hit a brick wall. GNU's std::string implementation stores an

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On 17/07/18 16:29, aliak00 wrote: A postblit on a class issues a compiler error. And an identity opAssign on a class also issues a compiler error. So I'm not sure how this would be different. And the page In https://dlang.org/spec/operatoroverloading.html also explicitly mentions

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Thursday, 12 July 2018 at 10:24:40 UTC, Shachar Shemesh wrote: On 29/06/18 15:35, aliak wrote: On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: Thanks in advance for your participation. For those of you using

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On 14/07/18 15:56, Johan Engelen wrote: First off: I am trying to wear a strict language lawyer hat. D spec is already very much ill specced which is _very_ problematic for language and compiler development. I am not attacking the proposal in order to kill it. I am merely commenting on points

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Thursday, 12 July 2018 at 10:22:33 UTC, Shachar Shemesh wrote: On 11/07/18 20:04, Johan Engelen wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: DIP 1014, "Hooking D's struct move semantics", is now ready for final review. after quick read: (would be much easier to

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Thursday, 12 July 2018 at 10:38:52 UTC, Shachar Shemesh wrote: On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure if going to copy constructors means that we should do something> different with this. It don't think that it's affected by it, but I could be> missing something. I

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On 12/07/18 04:17, Jonathan M Davis wrote:> I'm also> not sure if going to copy constructors means that we should do something> different with this. It don't think that it's affected by it, but I could be> missing something. I actually had that very same concern myself. Andrei does not seem

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On 29/06/18 15:35, aliak wrote: On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: Thanks in advance for your participation. For those of you using the NNTP or mailing list interfaces, this is the thread to respond

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On 11/07/18 20:04, Johan Engelen wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: DIP 1014, "Hooking D's struct move semantics", is now ready for final review. after quick read: (would be much easier to do inline commenting, but it appears that's not supported) ###

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Wednesday, 27 June 2018 01:13:14 MDT Mike Parker via Digitalmars-d wrote: > DIP 1014, "Hooking D's struct move semantics", is now ready for > final review. This is a last chance for community feedback before > the DIP is handed off to Walter and Andrei for the Formal > Assessment. Please read

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: DIP 1014, "Hooking D's struct move semantics", is now ready for final review. after quick read: (would be much easier to do inline commenting, but it appears that's not supported) ### Section "Code emitted by the compiler on

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Thursday, 5 July 2018 at 10:27:52 UTC, Dukc wrote: The DIP looks well written. I'm in favour of it. However, we need to consider how well this interacts with Razvan's DIP [1]. We should consider this together with it, so the implementations do not end up messing each other. 1:

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: DIP 1014, "Hooking D's struct move semantics", is now ready for final review. Structs are a low level feature that should be able to be used in any way programmer sees fit. This is just what is wrong with C# structs: In principle

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Wednesday, 27 June 2018 at 07:24:05 UTC, Mike Parker wrote: On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: Thanks in advance for your participation. For those of you using the NNTP or mailing list interfaces, this is the thread to respond in. Thanks! Alo! This is

Re: DIP 1014--Hooking D's struct move semantics--Final Review Begins

On Wednesday, 27 June 2018 at 07:28:07 UTC, Mike Parker wrote: On Wednesday, 27 June 2018 at 07:26:20 UTC, Mike Parker wrote: https://forum.dlang.org/post/hwscnvmtrzfcfnppd...@forum.dlang.org And I've pasted the wrong link here. The correct thread link is this one:

Re: DIP 1014--Hooking D's struct move semantics--Final Review Begins

On Wednesday, 27 June 2018 at 07:26:20 UTC, Mike Parker wrote: https://forum.dlang.org/post/hwscnvmtrzfcfnppd...@forum.dlang.org And I've pasted the wrong link here. The correct thread link is this one: https://forum.dlang.org/post/ipidsodqhgazrfvzh...@forum.dlang.org Thanks!

Re: DIP 1014--Hooking D's struct move semantics--Final Review

On Wednesday, 27 June 2018 at 07:13:14 UTC, Mike Parker wrote: Thanks in advance for your participation. For those of you using the NNTP or mailing list interfaces, this is the thread to respond in. Thanks!

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

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