Re: [boost] [variant] Opinion on boost::safe_get<> and default boost::get<> behavior

Subject: Re: [boost] [variant] Opinion on boost::safe_get<> and default boost::get<> behavior
From: Peter Dimov (lists_at_[hidden])
Date: 2014-12-09 12:39:34

Antony Polukhin wrote:
...
> boost::variant<int, string> v(100);
>
> boost::safe_get<bool>(&v); // compile time error
> boost::safe_get<bool>(v);   // compile time error
> boost::unsafe_get<bool>(&v); // returns NULL instead of compile time error
> boost::unsafe_get<bool>(v);   // throws exception on runtime instead of 
> compile time error
>
>
> I'm in doubt, what the default behavior of boost::get must be:
> * safe_get behavior is much closer to Standard Library behavior (just like 
> std::get for tuples) and allows to avoid errors in user code
> * unsafe_get behavior is same as behavior of old boost::get and won't 
> break user's code if boost::get is used in some generic contexs
>
> What's your opinion?

My opinion is that these functions are misnamed. unsafe_get is not unsafe. 
I'd say that they are strict and relaxed, respectively, not safe and unsafe.

Regarding the default, there's only one way to find out. Namely, you switch 
boost::get to be strict, then see if there are any complaints. (Having the 
default be relaxed doesn't seem to make much sense.)

There's nothing wrong (or unsafe) with the old behavior - it consistently 
answers the question "does v contain a T" - so the decision can't be made 
based on principles alone and must be informed by practice. That is, do the 
benefits of the strict get - which are pretty much only catching your typo 
when you say get<T>(v) instead of get<T>(w) - outweigh the loss of 
functionality.