LEWGI recommened to avoid operators >> and << for numeric types.

We need a paper that:

• Does a small research of the problem
• Provides a list of simpler alternatives (to_string, to_chars, etc.)
• Recommends a replacement for converting numbers<->strings (for example std::to_chars and std::from_chars)

LEWGI review noted that we may avoid std::common_type specializations for wide_integers if we can make ternary operator for wide_integers behave as intended.

We need some experiments and either an in detail description of why ternary operator fails or a paper that addresses the problem and removes the std::common_type specializations

We need to:

• add constexpr (but not noexcept!)
• use spaceship operator
• replace macro with aliases
• fix typos

We need a high level and example based introduction for the Numbers.

There are members that provide access to internals of unbounded integer. There may be more places like that.

We need a paper with detailed description of "why we do not whant to describe underlying implementations", possible ways to portably access storage in the future, and a wording to remove the unnecessary stuff.

We need a short sentence that describes the Numbers TS and a prioritized list of goals.

My best attempt
Scope: "User friendly numeric types, aliases and low level building blocks to implement them"

Goals:

1. Provide integral types that are widely useful and exist in other programming languages:
   a. integer - an unbounded integer type
   b. wide_integer - a non allocating integer of a compile time specified size
   c. elastic_integer - never overflowing integer that at compile-time generalize promotion rules
   d. safe_integer ???
2. Provide non-integral types that are widely useful and exist in other programming languages:
   a. rational - allocating? rational number representation
   b. decimal ???
   c. unbounded float ???
3. Provide basic building blocks for overflow detection
4. Provide arithmetic operations for each numeric type
5. Provide basic locale-unaware string <> numeric conversions
6. Provide arithmetic operations for interaction of different numeric types

What we are NOT planning to provide:

• iosteams for numeric types
• trigonometric functions
• description of the storage format for numeric type
• ???

@zamazan4ik @johnmcfarlane @Lawrence-Crowl please tell what do you think about the goals and scope?

LEWGI requested an exploration of modern C++ style APIs for the low-level interfaces such as the overflow detecting functions.

Explore and write a paper if there's a better apporach than the bool operation(out*, data_type1, data_type2);

This paper shall be ported to Latex in file fixedpointfloat.tex and shall be included in ts.tex after wideinteger.tex

Use wideinteger.tex as an example.

They are in a bad shape right now https://thephd.github.io/concerns-sg6-numerics-ts

We have to fix them or move out of Numbers into a separate papers.

I've read the paper and see a lot of legacy stuff like macros and additions to C headers such as <cstdint> that should really be deprecated because they are not modules. This is hacking on a legacy foundation that seems very short-sighted. I think we should stop beating the dead horse of C and make a design that actually scales well.

New namespace such as std::math.

This way we are not bound by sudden collisions with C library. And we really need a fresh start.

Pretty much all numeric functions should be customization point objects

This should be obvious. That's the only way that scales to user-defined types. Consider std::sin. It has overloads for floating point and integral types and no support for user defined types. std::math::sin would call a .sin() member function if UDT provides it or pickup sin non-member found via ADL. Same for all other numeric functions.

No additions to C headers, no macros

There is no point. Especially adding templates. I want import std to import numeric functions (assuming the committee will take Bjarne's approach of packaging C++ stdlib as std). Macros can't be exported. Again, let libc rot, there is no way of salvaging it.

It is unclear why the [intro.operations] names are defined as they are. Also I'm sure a lot of C++ developers are familiar with 'standard' x86/64 assembler names.

This paper shall be ported to Latex in file rational.tex and shall be included in ts.tex after wideinteger.tex.

Use wideinteger.tex as an example.

This paper shall be ported to Latex in file rational.tex and shall be included in ts.tex after wideinteger.tex

Use wideinteger.tex as an example.