Date: Wed, 11 Dec 2024 04:24:21 +0300
On 12/11/24 02:31, Tom Honermann wrote:
> On 12/10/24 5:55 PM, Andrey Semashev via Std-Proposals wrote:
>> On 12/11/24 01:25, Thiago Macieira via Std-Proposals wrote:
>>
>>> Therefore, whether the library has signed indices/sizes or has uses
>>> for signed
>>> indices, it must deal with signed distances and therefore must have some
>>> signed API. And therefore the OP's point remains: since we must deal
>>> with
>>> signed anyway, shouldn't we solve the mix/match by removing the
>>> unsigneds?
>> No, the fix is to resolve problems of poor interaction between signed
>> and unsigned integers in the language. And the OP doesn't propose that.
>
> We can't feasibly fix that in the core language (other than by providing
> some kind of opt-in like new types, epochs, or profiles).
If the problem is severe enough and can only be solved by extending the
type system, I don't see why it shouldn't be done.
> On 12/10/24 5:55 PM, Andrey Semashev via Std-Proposals wrote:
>> On 12/11/24 01:25, Thiago Macieira via Std-Proposals wrote:
>>
>>> Therefore, whether the library has signed indices/sizes or has uses
>>> for signed
>>> indices, it must deal with signed distances and therefore must have some
>>> signed API. And therefore the OP's point remains: since we must deal
>>> with
>>> signed anyway, shouldn't we solve the mix/match by removing the
>>> unsigneds?
>> No, the fix is to resolve problems of poor interaction between signed
>> and unsigned integers in the language. And the OP doesn't propose that.
>
> We can't feasibly fix that in the core language (other than by providing
> some kind of opt-in like new types, epochs, or profiles).
If the problem is severe enough and can only be solved by extending the
type system, I don't see why it shouldn't be done.
Received on 2024-12-11 01:24:24