Date: Fri, 31 Mar 2023 11:00:03 -0400
Integer promotion, like overload resolution and name lookup, is a
minefield. But unlike those other notions, it's actually really easy to
experiment with making your own integer-like types "in userspace." I
strongly suggest that Frederick make a prototype of his desired
integer-like type *as a class type with overloaded operators*, and actually
use it for a while, to find out where the remaining trouble spots are. Many
of these trouble spots will be unforeseen and unpredicted by even the
cleverest *thinker*; they'll have to be found by experience. Also, moving
this type's implementation into the standard library will not magically fix
those trouble spots.
Having done that, the questions to be answered by the proposal are no longer
- What semantics do I actually want, concretely? and
- Are those semantics implementable? and
- Am I right that I actually want those semantics, or do they just create
new problems for me that I didn't foresee?
Instead, the question becomes
- Now that I have a library solution to my problem, is it worth putting *in
the standard*? or should I just publish my code on GitHub and call it a day?
https://github.com/johnmcfarlane/cnl
is related.
my $.02,
Arthur
On Fri, Mar 31, 2023 at 10:12 AM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 31/03/2023 13:47, Frederick Virchanza Gotham via Std-Proposals wrote:
> > So I wonder would it be good to have another set of integer types that
> > don't promote?
>
> Would it be too far fetched to generalize this, and propose a fully
> policy-based integer type, with individual policies to decide:
>
> - the bit width
> - if it is signed or unsigned
> - whether overflow/underflow is UB, or wrap around, or saturate
> - if it takes part in integer promotions or not
> - if it implicitly converts towards any other integer types, or forbids
> narrowing, or doesn't implicitly convert at all
> - etc.
>
> My 2 c,
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
minefield. But unlike those other notions, it's actually really easy to
experiment with making your own integer-like types "in userspace." I
strongly suggest that Frederick make a prototype of his desired
integer-like type *as a class type with overloaded operators*, and actually
use it for a while, to find out where the remaining trouble spots are. Many
of these trouble spots will be unforeseen and unpredicted by even the
cleverest *thinker*; they'll have to be found by experience. Also, moving
this type's implementation into the standard library will not magically fix
those trouble spots.
Having done that, the questions to be answered by the proposal are no longer
- What semantics do I actually want, concretely? and
- Are those semantics implementable? and
- Am I right that I actually want those semantics, or do they just create
new problems for me that I didn't foresee?
Instead, the question becomes
- Now that I have a library solution to my problem, is it worth putting *in
the standard*? or should I just publish my code on GitHub and call it a day?
https://github.com/johnmcfarlane/cnl
is related.
my $.02,
Arthur
On Fri, Mar 31, 2023 at 10:12 AM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:
> On 31/03/2023 13:47, Frederick Virchanza Gotham via Std-Proposals wrote:
> > So I wonder would it be good to have another set of integer types that
> > don't promote?
>
> Would it be too far fetched to generalize this, and propose a fully
> policy-based integer type, with individual policies to decide:
>
> - the bit width
> - if it is signed or unsigned
> - whether overflow/underflow is UB, or wrap around, or saturate
> - if it takes part in integer promotions or not
> - if it implicitly converts towards any other integer types, or forbids
> narrowing, or doesn't implicitly convert at all
> - etc.
>
> My 2 c,
> --
> Giuseppe D'Angelo
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-03-31 15:00:17