On 04/05/2023 13:51, Peter Sommerlad (C++) via Std-Proposals wrote:
> One can use enums class types as substitutes for the built-ins and then
> define operator^ to do exponentiation instead of bit-xor :-)
>
> And may be have a separate set of bit-fiddling types, where only the
> bitwise operators are defined.
>
> For a start see my https://github.com/PeterSommerlad/PSsimplesafeint
> which makes the bit operations only available for the unsinged replacements.
>
> Regards
> Peter.

Yes, it is always possible to use existing operators for different
purposes. But some people want /more/ operators, not just /different/ ones.

I agree with the idea that arithmetic and bitwise operations belong in
different types. In my own experiments making "better" integer types, I
separate the purposes.

Getting a bit off-topic, I think you are entirely wrong to consider
wrapping behaviour as "safe" for signed integer types. It makes the
behaviour /defined/, but very, very far from /safe/. In all but a few
particular circumstances, if your arithmetic (signed or unsigned)
overflows, your code is broken - possibly disastrously so. There are
many ways to handle the possibility of overflow, but none of them can in
any sense be called "safe". The /safe/ thing to do is make sure you
never have overflows.

I haven't read through more than a bit of your code, but it looks to me
like you have an error in your operator""_siNN functions - they will
accept values that are outside the valid range. I'm not sure of the
best way to get these working well, especially given that for example
"-128_si8" is handled as parsed as first making an si8 of value 128
(which should be a compile-time error), and then applying unary negation
to it. I think you might have to have new "potentially_siNN" types that
have underlying unsigned types, with a consteval conversion function to
siNN, and a consteval unary plus and minus function that does the final
compile-time range check.

But that would really be for a C++ discussion, like Usenet
comp.lang.c++, rather than for this list. (My email is
david.brown_at_[hidden] if you want to take it off-list.)

mvh.,

David





>
> David Brown via Std-Proposals wrote on 04.05.23 13:38:
>> On 04/05/2023 11:47, Timur Doumler via Std-Proposals wrote:
>>> I don't think we could ever have operator** because ** has a meaning
>>> in C++ today (multiplication followed by dereference, or double
>>> dereference). Am I missing something?
>>>
>>> Cheers, Timur
>>>
>>
>> Yes, "x ** y" currently parses as "x * (*y)". I don't know how that
>> could be resolved without making spaces more significant in token parsing.
>>
>> (Personally, I'd be happy to see the introduction of rules regulating
>> spacing in connection with operators - it would lead to neater, more
>> consistent code that is easier for mere humans to read. But the
>> standards committee have their little obsessions about backwards
>> compatibility of existing code, so I don't think that would be accepted!)
>>
>>
>> If only C++ allowed Unicode symbols and punctuation as identifier
>> letters, we could use "x ↑ y" for exponentiation (and annoy programmers
>> with limited keyboard layouts!).
>>
>>
>> David
>>
>
>