Ed Brey wrote:
>>> [Use of a member function instead of a free function.]
>>
>> It's easy to make this case if you assume dependent variants are an
>> edge case.
>
> Let's assume that dependent variants are not an edge case. Would you
> say that the advantages of tight binding for non-template cases and
> prettier syntax for dependent variants are each strong enough to
> justify a dual interface, i.e. free and member?
>
> Interestingly, of the two, I'd say that member is most natural and
> free is pragmatic, working around the compiler's lack of omnicience.
I'll also be needing variant a lot from inside template code. I dislike the
template keyword that gets in the way. IMO, the way to go is the
C++ cast style syntax: extract<T>(v). There should only be one way
to do this. Not two. And FWIW, there's a precedent. Although currently,
boost::tuples has two ways to access its elements get<N>(t) and t.get<N>(),
the TR (and the one that will be a part of the standard) for tuples does not
have the member get anymore. IMO, this is a strong case *for* the free
cast style and *against* the member function style. The variant and optional
should strive to follow tuple's lead. In fact, come to think of it, why not just:
get<T>(v)
???
--
Joel de Guzman
[EMAIL PROTECTED]
http://www.boost-consulting.com
http://spirit.sf.net
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
