Re: [boost] Interest in an 'either' library?

On Sun, Jun 23, 2013 at 3:52 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of David Sankel Sent: Saturday, June 22, 2013 6:47 PM To: boost@lists.boost.org Subject: Re: [boost] Interest in an 'either' library?

Hi Larry!

On Sat, Jun 22, 2013 at 9:17 AM, Larry Evans

...

On 06/21/13 11:35, David Sankel wrote:

...

**semantics**:

template< typename left_type, typename right_type> struct either { // postcondition, is_left() either( left_type );

// postcondition, is_right() either( right_type );

bool is_left() const; bool is_right() const;

// postcondition, is_left() either & operator=( left_type );

// postcondition, is_right() either & operator=( right_type );

// precondition, is_left() left_type left();

// precondition, is_right() right_type right(); private: };

**uses**:

**Use 1**: Can be used as an alternative to exceptions or the (error codes+set reference idiom):

either load_file(...);

vs.

error_code load_file( file_id &, ... );

or

// throws std::exception file_id load_file(...);

Isn't this like haskell's either:

http://www.haskell.org/ghc/docs/6.12.2/html/libraries/base-4.2.0.1/Dat a-Either.html

Yes. The proposed nomenclature (either, left, right) is intentionally mimicking that of Haskell.

It's a somewhat cosmetic issue, but I suspect that most of the use cases involve an expected and an unexpected (rather than both being equally likely), so I'm not sure that following Haskell's name is really a good idea?

The (either, left, right) wording is somewhat arbitrary. I do see some serious problems, though, with the (expected,unexpected) wording because it will mislead readers of code that doesn't use the exception alternative use case. For example, compare the following definition, optional< either< isbn_10, isbn_13 > > parse_isbn_string( std::string ); to the equivalent using the 'expected' wording, optional< expected< isbn_10, isbn_13 > > parse_isbn_string( std::string ); -- David Sankel