Re: [boost] any

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-09-04 07:35:45

In message <01a101c01669$12b67b20$3e0524d4_at_pdimov>, Peter Dimov
<pdimov_at_[hidden]> writes
>It is not the inclusion itself I am discussing, but its form. any_cast is a
>free function, why not make copy_to a free function as well?

The case for any_cast as free function is much clearer: Its intended use
as a cast-like function. Form follows function.

>> >This makes copy_to even more generic.
>>
>> I don't see that this actually buys me very much.
>
>Offhand I don't see the exact benefits either, but the users may find an use
>for this idiom. Genericity is good, unless there are strong reasons against
>it.

I'm not keen on bells and whistles for their own sake, which is what
this sounds like.

>to_ptr((T*)0) is an unsupported 'hack' for MSVC users only; and while
>definitely 'ugly', it does no harm to the 'any' concept.

Judging by the recent discussion re VC7 it is a long term hack. If
someone wished to make their code portable, they would rely on that
hack, and away you go: permanence.

>> By providing my own function object type.
>
>You're still free to do that, if you don't like the default. If you can
>propose a better default, I'll be glad to consider it.

The point I am making is that there is no reasonable default, therefore
one should not be provided. For the same reason that type_info does not
support operator<, neither should ref. operator== makes sense, but
unless you actually have a proper ordering, operator< should be omitted
in favour of providing the user with a named, documented ordering
function object type.
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Ltd                   mobile: [phone]
  kevlin_at_[hidden]            fax:    [phone]
____________________________________________________________