https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #24 from Tomer Filiba (weka) <to...@weka.io> --- > We should address this situation by having writeln take scope inputs. It does > not escape any pointers. So... more special cases? > 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. --