Re: [boost] is_range metafunction

Subject: Re: [boost] is_range metafunction
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2008-10-05 21:37:13

On Sun, Oct 5, 2008 at 7:54 PM, Mathias Gaunard
<mathias.gaunard_at_[hidden]> wrote:
> Daniel Walker wrote:
>
>> Is there any other option? I mean if t<x> is ill-formed, because the
>> type x doesn't support some expression used in the template t, then is
>> there some context where t could be instantiated with x without making
>> the whole program ill-formed? I can't think of one.
>
> SFINAE for expressions, available in C++0x (GCC 4.4 implements it, albeit
> only with sizeof and not with decltype).

That's great news! That would do the trick!

>> If there were such a context, then you might be able associate t<x>'s
>> ill-formation with some boolean constant, and you would have a way to
>> implement tests based on concept checking templates - a sort of
>> concept-based type introspection for C++03, which would be way cool.
>
> That thing is mostly already doable in C++03.
> See this, for example:
> <http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_traits/doc/>

This is the first I've heard of this project, but from skimming the
documentation, I gather this library is not actually testing for
concepts (as in restraints on expressions), but instead it is testing
for class members. So, this approach couldn't cover concepts from the
BGL or Boost.Range or even the standard library's Swappable, because
none of these concepts are defined in terms of class members. They're
defined in terms expressions: begin(range) rather than range.begin(),
swap(x, y) rather than x.swap(y). Thus, to test for concepts you need
to be able to recover from ill-formed expressions... if expression
SFINAE with sizeof() actually works, that could have big
implications... a compile-time eval? You could write is_compilable()!
;-)

>> This brings up an interesting question regarding the proposed concept
>> language extensions for C++0x: If a function in an overload set
>> requires a concept that its argument doesn't model but some other
>> function in the set accepts the argument, does overload resolution
>> succeed?
>
> Of course.

Yes, I'm also glad to hear this. Do you know if this is supported in
ConceptGCC already? It's not clear to me from the documentation.
Actually, I should just download it and play around. Thanks!

Daniel Walker