On 29/03/18 15:43, Basile B. wrote:
Hi, simple question:
I wonder why the operator you want to add is not a member function ?
As far as i see (or as far i understand should i say) __move_post_blt
would be a free function, right ?
It it's by necessity, there's probably something missing in your DIP.
__move_post_blt is just a compiler/run time library implementation
detail. The important addition is opMove, which is a user defined
function, and is a member.
My first draft actually did place __move_post_blt as a member of the
struct. I quickly realized, however, that there is very little to gain
and lots to lose. I'll try to list some of the reasons:
* Implicitly defined by the compiler
The function would be added to the struct by the compiler, whether you
actually defined it or not. This opens a whole set of complications: do
we return it when you enumerate the struct's methods? If so, we enter a
minefield of backwards compatibility problems. If not, we're breaking
promises.
* Little to gain by allowing overriding the default
The main reason to define it as part of the struct is to allow
overriding the default behavior. The only advantage that would bring,
however, is if you want to prevent the opMove of one of your members
from running. I fail to see a use case for this.
Quite the contrary, I think opMove should prevent you from making stupid
mistakes as much as possible. The first version of the PR actually had
opMove's source reference be const, ensuring that you have a pristine
copy to investigate if you so wish. Following some feedback from Andrei,
I downgraded this to merely recommending it be const via the
documentation, but not failing the compilation if you choose to keep it
mutable.
If you provide me with cases where you think it makes sense for a
containing struct to prevent the opMove defined in one of its members
from running, we can have a more focused discussion.
Shachar
