Boost C++ Libraries: Ticket #12136: Propose lexical_cast type traits https://svn.boost.org/trac10/ticket/12136 <p> Please may I request the addition of type traits to the <code>lexical_cast</code> library which allow users to determine whether some type <code>T</code> can be <code>lexical_cast</code>ed? </p> <p> More specifically, it might be worth providing different traits to allow users to separately determine whether a type is ostreamable or istreamable. </p> <p> I think this would be a useful addition to the library. </p> en-us Boost C++ Libraries /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/12136 Trac 1.4.3 Antony Polukhin Tue, 19 Apr 2016 05:40:14 GMT <link>https://svn.boost.org/trac10/ticket/12136#comment:1 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/12136#comment:1</guid> <description> <p> <a class="missing wiki">LexicalCast</a> requires default construction and istreamable/ostreamable from operator: </p> <pre class="wiki">template &lt;class T&gt; struct is_lcast_istreamable: mpl::bool_&lt; (is_default_constructible&lt;T&gt;::value &amp;&amp; (boost::has_right_shift&lt;std::basic_istream&lt;wchar_t&gt;, T&gt;::value || boost::has_right_shift&lt;std::basic_istream&lt;char&gt;, T&gt;::value) ) &gt;{}; </pre><p> You can make the <code>is_lcast_ostreamable</code> similarly. Or you could just use the <a class="ext-link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4436.pdf"><span class="icon">​</span>detection idiom</a>. </p> <p> Anyway, such trait seems to have limited usage. I'd rather not add it and keep the interface of the <a class="missing wiki">LexicalCast</a> library as simple as possible. </p> </description> <category>Ticket</category> </item> <item> <author>Tony Lewis <tonyelewis@…></author> <pubDate>Tue, 19 Apr 2016 14:38:47 GMT</pubDate> <title/> <link>https://svn.boost.org/trac10/ticket/12136#comment:2 </link> <guid isPermaLink="false">https://svn.boost.org/trac10/ticket/12136#comment:2</guid> <description> <p> Thanks for detection idiom pointer - look interesting. </p> <p> Thanks for suggested implementation. </p> <p> Thoughts: </p> <ul><li>Though people technically <em>can</em> implement their own trait code (like your suggested implementation), they probably <em>shouldn't</em> 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. </li><li>I wholeheartedly agree that <code>lexical_cast</code>'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. </li></ul><p> Thanks very much. </p> </description> <category>Ticket</category> </item> <item> <dc:creator>Antony Polukhin</dc:creator> <pubDate>Sun, 09 Sep 2018 20:11:32 GMT</pubDate> <title>status changed; resolution set https://svn.boost.org/trac10/ticket/12136#comment:3 https://svn.boost.org/trac10/ticket/12136#comment:3 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">wontfix</span> </li> </ul> <p> 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. </p> Ticket