Date: Wed, 30 Jan 2019 20:40:03 +0000
On Wed, 30 Jan 2019 at 17:47 Jens Maurer <Jens.Maurer_at_[hidden]> wrote:
> On 01/30/2019 10:37 AM, John McFarlane wrote:
> > Can I take this opportunity to recommend that we consider library
> solutions to our numerics problems? There are mature, widely used
> class-based literal types out there which tackle such problems. (And yes,
> they support wrap, trap, snap and crap.) We could put a lot more effort
> into exploring their standardization.
>
> I thought SG6 was working on that. There were design overview
> papers discussed in SG6 at some Kona meeting years ago.
>
> Where did that go?
>
Briefly, from what I recall of the last few years' submissions...
In 2015, Lawrence proposed a Numerics TS in P0101 including an
overflow-handling type in P0106 (including wrap, trap and snap). There was
also P0105 which proposed free arithmetic functions to handle overflow in
fundamental types.
Robert Ramey proposed a safe integer type in 2016 in P0288 then decided
that taking the Boost route would have more impact.
In 2017, P0105 was revised. That same year, I wrote a position paper,
P0554, aimed at selling the idea of separating out P0106 types into
different single-responsibility types. It included a fairly typical 'safe
integer' type not dissimilar to Robert's.
Last year, Federico Kircheis published a safe integral comparisons papers
which overlaps the problem space of P0105. And I published P0828 with a
type which widens its results to avoid overflow. (Both Robert's and
Lawrence's types offer this.)
That's about all I've seen happening in this space in four years. No other
evidence of a Numerics TS and only a handful of proposals that might live
in it if there was. But there is some demand for safer integers. The
problem space is well explored with a good few solutions in the public
domain including from Microsoft and LLVM. (Other languages such as Swift,
Rust and Python are doing great things here too.)
John
> Jens
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
> On 01/30/2019 10:37 AM, John McFarlane wrote:
> > Can I take this opportunity to recommend that we consider library
> solutions to our numerics problems? There are mature, widely used
> class-based literal types out there which tackle such problems. (And yes,
> they support wrap, trap, snap and crap.) We could put a lot more effort
> into exploring their standardization.
>
> I thought SG6 was working on that. There were design overview
> papers discussed in SG6 at some Kona meeting years ago.
>
> Where did that go?
>
Briefly, from what I recall of the last few years' submissions...
In 2015, Lawrence proposed a Numerics TS in P0101 including an
overflow-handling type in P0106 (including wrap, trap and snap). There was
also P0105 which proposed free arithmetic functions to handle overflow in
fundamental types.
Robert Ramey proposed a safe integer type in 2016 in P0288 then decided
that taking the Boost route would have more impact.
In 2017, P0105 was revised. That same year, I wrote a position paper,
P0554, aimed at selling the idea of separating out P0106 types into
different single-responsibility types. It included a fairly typical 'safe
integer' type not dissimilar to Robert's.
Last year, Federico Kircheis published a safe integral comparisons papers
which overlaps the problem space of P0105. And I published P0828 with a
type which widens its results to avoid overflow. (Both Robert's and
Lawrence's types offer this.)
That's about all I've seen happening in this space in four years. No other
evidence of a Numerics TS and only a handful of proposals that might live
in it if there was. But there is some demand for safer integers. The
problem space is well explored with a good few solutions in the public
domain including from Microsoft and LLVM. (Other languages such as Swift,
Rust and Python are doing great things here too.)
John
> Jens
>
> _______________________________________________
> ub mailing list
> ub_at_[hidden]
> http://www.open-std.org/mailman/listinfo/ub
>
Received on 2019-01-30 21:40:17