[Development] qsizetype
A. Pönitz
apoenitz at t-online.de
Sat Mar 11 09:48:10 CET 2023
On Thu, Mar 09, 2023 at 02:08:48PM +0100, Hasselmann Mathias via Development wrote:
> My take on qsizetype: Just revert this failed experiment.
>
> It's a huge annoyance for little to no benefit.
Correct.
> I'll never understand how this very broken and incomplete experiment could
> make it into Qt's main branch at all.
Strangely enough I don't find any sensibly usable written record of this,
so I can only quote my own memory, which is a system I occacsionally accept
input from but that I don't recommend to trust. But I can at least give my
own reasoning why "this" could happen.
I /believe/ the issue was discussed (at least?) twice on Thursday at the
Qt Contributor summit 2019,
I also /believe/ this was somewhat controversial, and I /believe/ a discussed,
and even /promised/ possible mitigation was to keep qsizetype configurable like
qreal was for a while (for slightly different reasons, and arguably not exactly
helpful either, but...)
That would surely not have been optimal from my personal perspective, but "good
enough" for the time being, as this is structurally one of those "political"
things that is impossible to stop by reason, and there is only a limited number
of problems one can address at a time. My personal hope here was to be able to
chicken out by defining configuring qsizetype to int for my own uses and wait
for history's corrective measures.
Unfortunately for myself (and I am ready to take some blame for this ignorance)
there was this parallel, and for me on first sight unrelated, development of
the Q*View zoo, that started to set sizeof(qsizeype) == sizeof(std::size_t)
in stone and which currently seems to be the main obstacle to have a
configurable sizeof(qsizetype). It is surely possible (and in my view sensible)
to have sizeof(Q*View::size_type) == sizeof(std::size_t) *while keeping*
qize_type == int), but I wouldn't bet on this kind of outcome.
Andre'
More information about the Development
mailing list