https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #25 from Andrei Alexandrescu <and...@erdani.com> --- (In reply to Tomer Filiba (weka) from comment #24) > > We should address this situation by having writeln take scope inputs. It > > does > > not escape any pointers. > > So... more special cases? That's a straight use of scope per DIP 1000, in fact the very design intent: scope in a function signature specifies the function won't escape the parameter. > > I think immovability is a red herring. The problem is a pointer is escaped > > and it shouldn't be. Even if the struct were immovable, you could construct > > other cases in which &this gets messed up. > > Of course I could *make* it fail, but that would require me doing memcpy or > what not. It escapes the type system. I'm trying to make it work or fail > inside the type system. > > The whole point is that `struct S` cannot tell how people will use it. The > author thought people would just do > > void func() { > auto s = S(100); > // ... > // when s goes out of scope it will cancel the callback > } > > The author tried to prevent people from shooting themselves in the foot by > making the struct immovable. But then someone added a wrapper function that > returns a `struct S`. This second author knew the struct is immovable and > trusted the type system so his changes would either not compile, or compile > but never move the object. The code works in the happy flow, but when > things go south, all of the sudden you get cryptic bugs that take many days > -- and a lot of luck -- to track down. > > In this specific example, the struct registers a timer to be called in XX > seconds and kill the operation. Other examples could be a struct that adds > itself to a link-list and removes itself when it's destroyed. > > It doesn't make sense that C++ gives me this guarantee, but D fools me into > thinking my code is okay when in fact it isn't. It's not an implementation > detail or an optimization -- it's a semantic guarantee. What I'm saying is the problem is different: the address of this should not escape a non-scope method (including the constructor), we're in a world of trouble regardless whether we introduce a new feature regarding movability. --