Re: [boost] Pimpl Again?

Subject: Re: [boost] Pimpl Again?
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-05-31 21:40:19

On 1/06/2016 12:35, Vladimir Batov wrote:
> I am not sure if "to allow free function invocation syntax to invoke
> member functions and vice-versa" is exactly what Emil wanted. Quoting
> from the top --
> the "declaration of non-friend "member" functions outside of the type
> definition". I read it as Emil wants it to be a "member" but declared
> "outside".

That's what extension methods are though, as I mentioned in my other post.

They're free functions declared outside of the class (and thus don't 
have access to private/protected members) that take the class as their 
initial (or possibly only) parameter.

What makes them actual extension methods is that the language allows 
them to be called as if they were members -- ie. at the compiler level, 
it finds this:

    a.f(b);

and if it fails to find a "real" member f on a, but it can find a 
compatible free function, then it will pretend that the code had said 
this instead:

    f(a, b);

This allows external code to define additional methods that aren't 
actually part of a class but can be called as if they were, which 
enables some quite nice things.

For example, imagine a library that could add string algorithms directly 
to std::string (as far as it appears from the call syntax).

Though the real power typically comes from defining extensions for 
concepts rather than concrete types, though both are useful.

(An odd side effect of this, which is both good and bad, is that it also 
allows well-formed "member" calls on nullptr with a well-defined result.)