Opened 7 years ago

Closed 4 years ago

#12136 closed Feature Requests (wontfix)

Propose lexical_cast type traits

Reported by: Tony Lewis <tonyelewis@…> Owned by: Antony Polukhin
Milestone: To Be Determined Component: lexical_cast
Version: Boost 1.61.0 Severity: Optimization
Keywords: lexical_cast, trait, ostreamable, istreamable, lexical_castable Cc:

Description

Please may I request the addition of type traits to the lexical_cast library which allow users to determine whether some type T can be lexical_casted?

More specifically, it might be worth providing different traits to allow users to separately determine whether a type is ostreamable or istreamable.

I think this would be a useful addition to the library.

Change History (3)

comment:1 by Antony Polukhin, 7 years ago

LexicalCast requires default construction and istreamable/ostreamable from operator:

template <class T>
struct is_lcast_istreamable: mpl::bool_<
    (is_default_constructible<T>::value &&
        (boost::has_right_shift<std::basic_istream<wchar_t>, T>::value || 
         boost::has_right_shift<std::basic_istream<char>, T>::value)
    )
>{};

You can make the is_lcast_ostreamable similarly. Or you could just use the detection idiom.

Anyway, such trait seems to have limited usage. I'd rather not add it and keep the interface of the LexicalCast library as simple as possible.

Last edited 7 years ago by Antony Polukhin (previous) (diff)

comment:2 by Tony Lewis <tonyelewis@…>, 7 years ago

Thanks for detection idiom pointer - look interesting.

Thanks for suggested implementation.

Thoughts:

  • Though people technically can implement their own trait code (like your suggested implementation), they probably shouldn't because, AFAIA, the library doesn't present this expression as part of it's interface, ie using it means depending on the library's internals. Unless the library's public documentation can guarantee that this expression is guaranteed to remain correct, this functionality is best provided by the library so it can insulate users' code from changes to the internals.
  • I wholeheartedly agree that lexical_cast's simple interface is one of its strengths. That said, I think the proposed traits would add very little complexity and could be kept to a corner of the documentation so they don't confuse new users.

Thanks very much.

comment:3 by Antony Polukhin, 4 years ago

Resolution: wontfix
Status: newclosed

After 2 years of thought I came to the decision to not add the trait. People who need it could invent it on their own, others probably should not know about it at all.

Note: See TracTickets for help on using tickets.