Date: Thu, 9 Oct 2025 15:19:02 +0200
Wouldn't that be terrible?
To even cast function pointers?
So neither the caller nor the callee know that there was a 'conversion' between large positive and negative numbers?
I could imagine that this works well only for functions returning small positive numbers by contract.
-----Ursprüngliche Nachricht-----
Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Gesendet:Do 09.10.2025 15:06
Betreff:Re: [std-proposals] ranges::size should always return a unsigned integer
An:std-proposals_at_[hidden];
CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
On Thursday, October 9, 2025, Sebastian Wittmeier via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote:
What is the difference to static_cast<unsigned int>(size())
(or some suitably longer <size_t> type)
Or you want to definitely have functions differentiated (overloaded) by return type?
I was purely going for the ergonomics of it.
You're right though that it would sort of be like allowing function overloading by return type, but we could stipulate that the unsigned and signed forms of the function shall have the same address in memory (because the machine code will be the same anyway). So then the trigraph, +|- , would really do nothing more than convert a function pointer to another function pointer type.
What I mean, is that if you had the following function pointer:
uint64_t (*p)(void)
and if you were to place +|- before it, then the following expression:
+|- p
would be the same as:
( (int64_t (*)(void)) p)
So you're not really providing an alternative implementation in the true sense of "function overloading", but more so you're just casting a function pointer before you invoke it. This will work fine on every CPU instruction set I can think of . . . arm 32 & 64, x86 32 & 64, hppa, motorolla, PowerPC, RISC, Sparc.
Again it's just a half-baked idea.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-10-09 13:31:36
