• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
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&lt;T&gt; 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&lt;&gt; 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&lt;typename T&gt;
43struct range {
44    T m_lowest;
45    T m_highest;
46    // default implementation
47    range(
48        const &amp; T t_min,
49        const &amp; T t_max
50    ) :
51        m_lowest(std::numeric_limits&lt;T&gt;::lowest(t_min),
52        m_highest(std::numeric_limits&lt;T&gt;::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&lt;T&gt; 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&lt;T&gt; 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&lt;T&gt;</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