RE: [boost] Re: compile time member detection

From: Brock Peabody (brock.peabody_at_[hidden])
Date: 2003-11-13 23:22:34

> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> On Behalf Of David Abrahams
> 
> This sort of thing really worries me in generic code, because the name
> alone is not enough to identify the semantics.  It's one thing to say,
> "if this thing has a clone function AND its signature contains a
> special type that you can only know about if you also know about the
> way my library looks for clone functions, then...", but when you just
> check for a clone function as you do above, you're relying on everyone
> having an agreement about the meaning of "clone".
> 
> OK, so maybe clone is more likely to be agreed upon than the semantics
> of most other member function names.  I hope you get my point, though.
> It's easy to create really broken "generic" designs with these sorts of
> tests.  You have to use them very carefully.

In a way, it reminds me of the ability in certain dynamically typed
languages to be able to attempt at run time to call any function on an
object.  I agree that this type of capability is dangerous!  At least we can
catch syntactic mismatches at compile time, but the possibility for semantic
mismatches remains, as you pointed out.  Of course, there is no way to
guarantee semantics, but I would hope that people wouldn't be using
different classes in the same library that had functions whose signatures
matched exactly but which had different meanings.

On the other hand, is it really _that_ much different from any other generic
algorithm?  say:

   template <typename T> T* clone(const T& t) { return new T(t);}

We're still relying on a common understanding of what 'clone' means.

Hopefully people are beginning to see the light about verbose, unambiguous
naming.  Boost is certainly setting a good example.

> > I think people will begin to see more opportunities to use this type of
> > introspection, especially with the advent of tools like enable_if.
> 
> I'm a bit worried about that very thing.

I can't say I disagree with you.  People could make some awful designs with
this type of thing.  I agree that it remains to be seen if you can do really
useful things with it.  My instinct though is that for better or worse
people are going to be expecting more and more compile time introspection
capabilities from the language itself.  SFINAE is just the tip of the
iceberg.  Some day it's going to be possible to do things like enumerate the
members of a class at compile time and it's not too early to start thinking
about what good and what bad can come from it.

Brock