Re: [boost] [typeof] Determining if a type has been registered or not at compile time

Subject: Re: [boost] [typeof] Determining if a type has been registered or not at compile time
From: Edward Diener (eldiener_at_[hidden])
Date: 2009-12-27 17:15:15

Peder Holt wrote:
>>
>>  One way to workaroun this is to allow the user to add a default type:
>>> typedef
>>>
>>> BOOST_TYPEOF_WITH_DEFAULT(some_expression,some_backup_type_if_some_expression_not_registered)
>>> type;
>>>
>>> Is this acceptable?
>>>
>> Yes, that seems the best solution. An excellent idea. Should I create a
>> Trac suggestion for it or will you remember to implement it if you decide to
>> do it ? If you do this, I think you will want to do it for TYPEOF_TPL also.
>> I see much less use for AUTO and AUTO_TPL defaults if the type is not
>> registered but I think you should also implement it for these two also both
>> to be orthogonal and for the possibility that someone will find a use there
>> also.
>>
>>
> I will remember :)
> I am, however, not sure about the proper name for this beast. Also, I am a
> bit uncertain about the best behaviour:
> 
> I see mainly two options:
> 1)
> typedef BOOST_TYPEOF_WITH_DEFAULT(expression,typename
> some_alternative_expression::type) type;

I assume the second parameter is any user-specified type.

> 
> 2)
> typedef BOOST_TYPEOF_WITH_DEFAULT(expression,no_type) deduced_type;
> typedef mpl::eval_if<
>                boost::is_same<deduced_type,no_type>,
>                boost::mpl::identity<deduced_type>,
>                some_alternative_expression
>> ::type type;
> 
> In the second alternative we could simplify the name to
> BOOST_SAFE_TYPEOF(expression) or
> BOOST_NONFAILING_TYPEOF(expression) or
> BOOST_TYPEOF_OR_NONE(expression) or
> BOOST_Your_idea_goes_here(expression)
> 
> And, yes, I agree that this should be implemented for TPL. Only the first
> alternative can be implemented with AUTO...
> 
> Another alternative is to implement alternative 1 an then alternative 2 by
> using alternative 1. I am still unsure about the name.
> BOOST_TYPEOF_WITH_DEFAULT seems a very long name, and not overly descriptive
> either.

I would suggest 1) to allow the end-user to specify the default type if 
the expression's type can not be deduced.

I would also suggest in 2) the BOOST_SAFE_TYPEOF(expression) where you 
supply a 'boost::typeof::no_type' type ( as an empty struct ) 
automatically if the expression's type can not be deduced. This way you 
give the end-user the most flexibility. Needless to say the 
'boost::typeof::no_type' should be available for the end-user to use 
also in the BOOST_TYPEOF_WITH_DEFAULT case if he chooses ( within a 
boost::mpl::identity of course ).

I think BOOST_TYPEOF_WITH_DEFAULT is fine as a name and 
BOOST_SAFE_TYPEOF is decent also. I personally always seek clarity in a 
name and never a clever shortness, but whatever names you choose I am 
sure will be fine. For the TPL names I would simply append  _TPL to the 
end of the TYPEOF word in both cases, giving you 
BOOST_TYPEOF_TPL_WITH_DEFAULT and BOOST_SAFE_TYPEOF_TPL.

As far as the BOOST_AUTO and BOOST_AUTO_TPL cases, although I see little 
practical use for the generation of a variable of the fallback type, I 
do not see technically why you can not have both cases with that also, 
as long as 'boost::typeof::no_type' is a valid type, but I am guessing 
you see something that I do not see. So I see no reason why you could 
not have BOOST_AUTO_WITH_DEFAULT(var,expression,alternative_type) and 
BOOST_SAFE_AUTO(var,expression) along with their TPL forms of 
BOOST_AUTO_TPL_WITH_DEFAULT(var,expression,alternative_type) and 
BOOST_SAFE_AUTO_TPL(var,expression).