Date: Mon, 7 Sep 2026 15:12:39 +0200
Hi,
> Date: 2026-09-07 14:50:48+0200
> From: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
>
> intptr_t is not a good choice for an arithmetic int type.
>
> What if pointers are 64 bits and optimum arithmetic width is 32 bits?
>
> E.g. GPUs.
>
> Or even CPU code may be compiled for AVX/SSE/SVE/...
>
> And there are a lot of standardized int alternatives now in <cstdint> - fast ones, small ones,
>
> https://en.cppreference.com/cpp/types/integer
>
> int_fast32_t could be a good type for those purposes.
int_fastN_t types are dead on arrival. They set ABI, which means they
can't be changed in the future if some type becomes faster. Also,
faster for what? In some cases, small types can result in faster code,
even if each arithmetic operation is slightly slower.
I'd say just use my_int_t in your code, and maintain a manual list of
underlying types which are fastest for your purposes in each system.
'int' is fine for most uses, and need not (and cannot) be deprecated.
Maybe the wording can be improved, to not say that it has the natural
size.
Have a lovely day!
Alex
> -----Ursprüngliche Nachricht-----
> Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet:Mo 07.09.2026 14:49
> Betreff:[std-proposals] Deprecate int
> An:std-proposals <std-proposals_at_[hidden]>;
> CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
> 'int' is no longer fit for purpose as described in the Standard:
>
> "Plain int's have the natural size suggested
> by the architecture of the execution environment"
>
> This isn't abided anymore, as all 64-Bit platforms have 32-Bit int's.
>
> It is for this reason that in my code I use 'uintptr_t' when I need
> the 'natural size' integer.
>
> Just this week, I found old code of mine that used 'uintptr_t', and I
> went looking for where in the code I converted a pointer to an int --
> but I couldn't find it. Then I realised that I was only using that
> type as the 'natural' type. So maybe we should have:
>
> namespace std {
> typedef intptr_t int_t;
> typedef uintptr_t uint_t;
> }
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
> Date: 2026-09-07 14:50:48+0200
> From: Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden]>
>
> intptr_t is not a good choice for an arithmetic int type.
>
> What if pointers are 64 bits and optimum arithmetic width is 32 bits?
>
> E.g. GPUs.
>
> Or even CPU code may be compiled for AVX/SSE/SVE/...
>
> And there are a lot of standardized int alternatives now in <cstdint> - fast ones, small ones,
>
> https://en.cppreference.com/cpp/types/integer
>
> int_fast32_t could be a good type for those purposes.
int_fastN_t types are dead on arrival. They set ABI, which means they
can't be changed in the future if some type becomes faster. Also,
faster for what? In some cases, small types can result in faster code,
even if each arithmetic operation is slightly slower.
I'd say just use my_int_t in your code, and maintain a manual list of
underlying types which are fastest for your purposes in each system.
'int' is fine for most uses, and need not (and cannot) be deprecated.
Maybe the wording can be improved, to not say that it has the natural
size.
Have a lovely day!
Alex
> -----Ursprüngliche Nachricht-----
> Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet:Mo 07.09.2026 14:49
> Betreff:[std-proposals] Deprecate int
> An:std-proposals <std-proposals_at_[hidden]>;
> CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
> 'int' is no longer fit for purpose as described in the Standard:
>
> "Plain int's have the natural size suggested
> by the architecture of the execution environment"
>
> This isn't abided anymore, as all 64-Bit platforms have 32-Bit int's.
>
> It is for this reason that in my code I use 'uintptr_t' when I need
> the 'natural size' integer.
>
> Just this week, I found old code of mine that used 'uintptr_t', and I
> went looking for where in the code I converted a pointer to an int --
> but I couldn't find it. Then I realised that I was only using that
> type as the 'natural' type. So maybe we should have:
>
> namespace std {
> typedef intptr_t int_t;
> typedef uintptr_t uint_t;
> }
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-- <https://www.alejandro-colomar.es>
Received on 2026-09-07 13:12:51
