[boost] Re: compile time member detection

From: David Abrahams (dave_at_[hidden])
Date: 2003-11-14 11:40:23

Mat Marcus <mat-boost_at_[hidden]> writes:

>>> 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.
>>
>> "Me too."
>>
>> In my opinion, "named conformance" is the right way to design most
>> interfaces, whereas "structural conformance" (as above) is the wrong
>> way.
>
> [snip]
>
> Named conformance worries me, though I haven't programmed much in
> Haskell yet. One question I have is: who writes the type classes (or
> whatever you want to call these things)? I can't imagine it is the
> library author since the generic (meta-)algorithms are meant to be
> used with an unbounded set of types(, metafunctions, etc.). But a
> library's usability would seem to suffer if the user has to manually
> assert conformance to various concepts before calling generic
> algorithms. A hybrid approach where the library author provides the
> named conformance for "common types" doesn't seem to help. I want the
> generic algorithm to be written in such a way that the compiler can
> check conformance for me. Are you really worried about accidental
> structural conformance? How do things work in practice in Haskell?

I think Jeremy/Jaakko/Andrew/et. al's recent paper shows that those
explicit declarations are a pain.

I'm not neccessarily opposed to some use of structural conformance,
if that's what we know we're doing.  What I think I *am* opposed to
are explicit decisions made based on structure without some check to
make sure that the structure isn't an accident.  It's the difference
between saying, "you can call this function provided you conform
structurally", and "If you have such-and-such structure, then you are
an X, and I will make further decisions based on that fact".

I realize that overloading in C++ and SFINAE (or in-language concepts)
can make these two technically equivalent, but I also think intent
matters.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com