• Max Haughton (6/6) Jul 11 2019 I think "DIP1000"(i.e. whatever it becomes) should eventually
• Paul Backus (6/12) Jul 11 2019 I don't think this can be done without adding something like
• Max Haughton (10/24) Jul 11 2019 wrt a borrow checker, we already have lifetimes so an extremely
• Paul Backus (3/5) Jul 11 2019 Well, presumably opPostMove is run *before* the source is set to
• Sebastiaan Koppe (4/10) Jul 11 2019 I agree. Made a post earlier about it.

Max Haughton <maxhaton gmail.com> writes:

I think "DIP1000"(i.e. whatever it becomes) should eventually 
disallow use after move.

This should probably be by default but allow tagging a move 
operator as safe to reuse.

I haven't got a clue where to start an implementation but I think 
this would be a good step once DIP1014 is implemented.

Paul Backus <snarwin gmail.com> writes:

On Thursday, 11 July 2019 at 10:19:16 UTC, Max Haughton wrote:
 I think "DIP1000"(i.e. whatever it becomes) should eventually 
 disallow use after move.

 This should probably be by default but allow tagging a move 
 operator as safe to reuse.

 I haven't got a clue where to start an implementation but I 
 think this would be a good step once DIP1014 is implemented.

I don't think this can be done without adding something like 
Rust's borrow checker to D.

Since D's `move` resets the moved-from object to its .init value, 
a use-after-move is just a logic error, not undefined behavior, 
so there's nothing un- safe about it.

Max Haughton <maxhaton gmail.com> writes:

On Thursday, 11 July 2019 at 13:33:03 UTC, Paul Backus wrote:
 On Thursday, 11 July 2019 at 10:19:16 UTC, Max Haughton wrote:
 I think "DIP1000"(i.e. whatever it becomes) should eventually 
 disallow use after move.

 This should probably be by default but allow tagging a move 
 operator as safe to reuse.

 I haven't got a clue where to start an implementation but I 
 think this would be a good step once DIP1014 is implemented.

 I don't think this can be done without adding something like 
 Rust's borrow checker to D.

 Since D's `move` resets the moved-from object to its .init 
 value, a use-after-move is just a logic error, not undefined 
 behavior, so there's nothing un- safe about it.

wrt a borrow checker, we already have lifetimes so an extremely 
basic borrow checker (if it could fit syntactically) would be 
interesting.


Move: Is that still the case after DIP1014, I.e. you can do 
arbitrary work in opPostMove... Right?

The system I propose is opt-in/out, i.e. avoidable either way, do 
you can choose to make it an error by tagging opPostMove. This 
could alleviate some fairly massive bugs that come with using 
move semantics by accidently reusing an invalid object.

Paul Backus <snarwin gmail.com> writes:

On Thursday, 11 July 2019 at 19:01:47 UTC, Max Haughton wrote:
 Move: Is that still the case after DIP1014, I.e. you can do 
 arbitrary work in opPostMove... Right?

Well, presumably opPostMove is run *before* the source is set to 
.init; it wouldn't make much sense otherwise.

Sebastiaan Koppe <mail skoppe.eu> writes:

On Thursday, 11 July 2019 at 10:19:16 UTC, Max Haughton wrote:
 I think "DIP1000"(i.e. whatever it becomes) should eventually 
 disallow use after move.

 This should probably be by default but allow tagging a move 
 operator as safe to reuse.

 I haven't got a clue where to start an implementation but I 
 think this would be a good step once DIP1014 is implemented.

I agree. Made a post earlier about it.

Just yesterday saw this: 
https://awesomekling.github.io/Catching-use-after-move-bugs-with-Clang-consumed-annotations/