1<?xml version="1.0" encoding="UTF-8"?> 2<!DOCTYPE section PUBLIC "-//Boost//DTD BoostBook XML V1.1//EN" 3"http://www.boost.org/tools/boostbook/dtd/boostbook.dtd"> 4<section id="safe_numerics.pending_issues"> 5 <title>Pending Issues</title> 6 7 <?dbhtml stop-chunking?> 8 9 <para>The library is under development. There are a number of issues still 10 pending.</para> 11 12 <section> 13 <title><code>safe_base</code> Only Works for Scalar Types</title> 14 15 <para>The following is paraphrased from an issue raised by Andrzej 16 Krzemieński as a <ulink 17 url="https://github.com/robertramey/safe_numerics/issues/44">github 18 issue</ulink>. It touches upon fundamental ideas behind the library and 19 how these ideas as the implementation of the library collided with 20 reality.</para> 21 22 <para><quote>In the current implementation safe<T> will only work 23 with T being a C++ scalar type. Therefore making a general type 24 requirements that say what operations are allowed is superfluous, and 25 confusing (because it implies that safe<> is more 26 generic.</quote></para> 27 28 <para>When I started out, It became clear that I wanted "safe" types to 29 look like "numeric" types. It also became clear pretty soon that there was 30 going to be significant template meta-programming in the implementation. 31 Normal type traits like std::is_integer are defined in the std namespace 32 and one is discouraged from extending it. Also I needed some compile time 33 "max" and "lowest" values. This lead me to base the design on 34 std::numeric_limits. But std::numeric limits is inherently extensible to 35 any "numeric" type. For example, money is a numeric type but not an 36 intrinsic types. So it seemed that I needed to define a "numeric" concept 37 which required that there be an implementation of std::numeric_limits for 38 any type T - such as money in this case. When I'm doubt - I tend to think 39 big.</para> 40 41 <para>For now though I'm not going to address it. For what it's worth, my 42 preference would be to do something like: <programlisting>template<typename T> 43struct range { 44 T m_lowest; 45 T m_highest; 46 // default implementation 47 range( 48 const & T t_min, 49 const & T t_max 50 ) : 51 m_lowest(std::numeric_limits<T>::lowest(t_min), 52 m_highest(std::numeric_limits<T>::max(t_max) 53 {} 54};</programlisting></para> 55 56 <para>Then redeclare <code>safe_base</code>, etc., accordingly.</para> 57 58 <para>Also not that for C++20, template value parameters are no longer 59 restricted to integer primitive types buy maybe class types as well. This 60 means the library maybe extended to user class types without changing the 61 current template signatures.</para> 62 </section> 63 64 <section> 65 <title>Concepts are Defined but Not Enforced.</title> 66 67 <para>The following is paraphrased from an issue raised by Andrzej 68 Krzemieński as a <ulink 69 url="https://github.com/robertramey/safe_numerics/issues/46">github 70 issue</ulink>.</para> 71 72 <para><quote>You do not need a concept to constrain anything with it, in 73 your library. Or is the purpose of the Type requirements to show in detail 74 what it means that safe<T> is a 'drop-in replacement for 75 T?</quote></para> 76 77 <para>Right - currently I don't use the concept to constrain anything. 78 They are currently a purely "conceptual" tool to keep the design from 79 getting off track. This is common with other libraries such as the C++ 80 standard library where the concepts are defined but not enforced by 81 compile time predicates. Hopefully in future that might change - see 82 below</para> 83 84 <para><quote>If you want to extend safe<T> for other integer types, 85 Type requirement still need to be fixed:</quote></para> 86 87 <para>Hmmmm - I'm not quite sure that this is true. One thing that IS true 88 is the the interface and implementation of the library will need to be 89 enhanced to permit "safe" to be applied to user defined types. This is 90 apparent now, but as my brain can only comprehend the library one piece at 91 a time, this design feature was lost during the implementation. In 92 implementing co-existence of floats with safe integers, I did refactor the 93 implementation in a way which I believe my eventually permit the 94 application to any user supplied T which implements all the required 95 operations of Numeric types. So as it is now this is pending. If the 96 library were to become widely used, there might be motivation to do this. 97 Time will tell. So for now I'm leaving these in the documentation and 98 code, even though they are not actually used.</para> 99 </section> 100 101 <section> 102 <title>Other Pending Issues</title> 103 104 <para><itemizedlist> 105 <listitem> 106 <para>The library is currently limited to integers. If there is 107 interest, it could be extended to floats and possible to user 108 defined types.</para> 109 </listitem> 110 111 <listitem> 112 <para>Although care has been taken to make the library portable, at 113 least some parts of the implementation - particularly 114 <code>checked</code> integer arithmetic - depend upon two's 115 complement representation of integers. Hence the library is probably 116 not currently portable to all other possible C++ architectures. 117 These days, this is unlikely to be a limitation in practice. 118 Starting with C++20, integer arithmetic will be guaranteed by the 119 C++ standard to be two's complement.</para> 120 </listitem> 121 122 <listitem> 123 <para><code>std::common_type</code> is used in a variety of generic 124 libraries, including std::chrono. Without a specialization for 125 <code>safe<T></code>s one cannot use the safe wrappers e.g. as 126 a representation for <code>std::chrono::duration</code>.</para> 127 </listitem> 128 </itemizedlist></para> 129 </section> 130</section> 131