On Sunday, April 01, 2018 12:23:29 Per Nordlöw via Digitalmars-d wrote: > On Sunday, 1 April 2018 at 01:56:40 UTC, Jonathan M Davis wrote: > > Another potential issue is whether any of this does or should > > relate to > > > > https://github.com/dlang/DIPs/pull/109 > > > > and it's solution for hooking into to moves. I'm not at all > > sure that what happens with that needs to be related to this at > > all, but it might. > > > > - Jonathan M Davis > > And before we think about `opMove` we should, IMO, make the > compiler pass by move in more cases, for instance, in range > constructors such as > > this(Source source) > { > this.source = source; // last occurrence of `source` can be > moved > } > > I'd be happy to help out with adding this in dmd. Andrei has > already showed interest in this idea.
I don't see what that has to do with opMove other than the fact that in such cases, you'd then end up with opMove being called instead of the postblit constructor. It seems to me that whether opMove is part of the language or not when such improvements are made is irrelevant. They should be able to be done independently of one other. As I understand it, the motivations behind opMove really have nothing to do with how often moves are made vs copying. It has to do with types that have serious issues if they're moved. The Weka guys (and probably others) have use cases where the fact that an object is moved without any way for them to detect it and do stuff like update pointers to the object is a serious problem. If anything, their use case might be better off right now if _no_ moves were ever done (at least until something like opMove is in the language), since the moves result in bugs. - Jonathan M Davis
