subject:"\[Development\] qsizetype"

Re: [Development] qsizetype

2023-03-11 Thread Thiago Macieira

On Saturday, 11 March 2023 00:48:10 PST A. Pönitz wrote:
> 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.

Not just size_t, and I don't think it's even the most important match. A lot 
of code in Qt 6 has begun assuming that sizeof(qsizetype) == sizeof(void *). 
That is, they are using qsizetype interchangeable with quintptr and qintptr. 
The view classes you're referring to above are not the only example; they may 
be the most visible one and thus the most correctable if we wanted to change, 
but it's very likely that there are many more hidden such uses inside the code 
that would just corrupt pointers left and right.

This is why I replied to Matthias that changing this is going to be more work 
than keep going now.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering

smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype

2023-03-11 Thread A . Pönitz

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'
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype

2023-03-09 Thread Thiago Macieira

On Thursday, 9 March 2023 05:08:48 PST Hasselmann Mathias via Development 
wrote:
> My take on qsizetype: Just revert this failed experiment. It's a huge
> annoyance for little to no benefit. I'll never understand how this very
> broken and incomplete experiment could make it into Qt's main branch at all.

Pretty sure reverting now would be even more disruptive than just fixing the 
remaining issues. It does mean Qt 7 anyway.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


smime.p7s
Description: S/MIME cryptographic signature
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] qsizetype

2023-03-09 Thread Hasselmann Mathias via Development

My take on qsizetype: Just revert this failed experiment. It's a huge
annoyance for little to no benefit. I'll never understand how this very
broken and incomplete experiment could make it into Qt's main branch at all.

Am 13.09.2022 um 15:12 schrieb Volker Hilsheimer:

On 12 Sep 2022, at 20:04, A. Pönitz wrote:

On Wed, Sep 07, 2022 at 06:38:30PM +0200, A. Pönitz wrote:

On Mon, Sep 05, 2022 at 05:15:45PM +, Marc Mutz wrote:

[...]
We have the tools (QT_REMOVED_SINCE + Ivan's work on
-disable-deprecated-until) to have a user-configurable, rolling BC window
now We should use these tools to avoid accumulating too much technical
[...]
That said, sometimes it's just simpler to do the API change together with
the rest. I wouldn't worry too much about the effect this has on users of
Qt APIs: Function argument widening is SC,

I currently fail to understand why all this work needs to have user-visible
consequences *at all* before 7.0 - especially, but not limited, to the now
apparently planned incoming stream of source-incompatible changes including
related deprecations starting to hard-hit users from 6.8 on.

What would have been wrong with starting with

#ifdef I_AM_WORKING_ON_IT
using qsizetyp_ = qsizetype;
#else
using qsizetyp_ = int;
#endif

then have the people working on it (and only those, plus perhaps potential
early adopters) define the macro locally, "port" int to qsizetyp_, and when
everyone is happy with the scope and the implication ofthe change, at 7.0 time,
globally replace qsizetyp_ by qsizetype ?

Why is all this done as operation at an "open heart" instead of having
a "staging" and "production" setup?

Could anyone involved in the decision making that resulted in
the approach taken here please comment?

I can't claim that I was involved in the decision making, but here’s how I see
it:

We have the tools to change - with some limitations - API signatures without
breaking either source or binary compatibility. We can deprecate and “weaken”
old overloads in favour of new overloads; or we can remove the old overload
completely from the public API and still continue to export the old symbol
through the module-specific ‘removed_api.cpp’ files.

This is conceptually great news, it gives us a bigger toolbox than what we had
before. Technically, this is very powerful and useful, allowing us to fix
mistakes gradually, while giving users control over what kind of deprecation
warning level they want (from completely silent, up to code no longer
compiling).

This is IMHO superior to a temporary type alias: A string-based signal/slot
connection where the signal has been ported ot emit a qsizetyp_ while the slot
still receives int will fail. So that would break source compatibility. But if
both slot overloads are still visible for moc when Qt is built, but not to the
compiler when Qt is used, then those connections will continue to work.

So, I think we have the right tools. The discussion we need to have is when to
use them. As I have proposed in this thread: this has to be a case by case
decision.

QTimer should allow timeouts longer than 2^31 msecs, i.e. < 25 days. Great that
we could fix this before Qt 7.

QDir::count and operator[] now work with qsizetype. I suppose there can be >2^31 files in
a directory, perhaps more so in 10 years than now. Nevertheless, I do wonder whether this is
worth the potential source compatibility breakage that is pointed out in the comment
message. But as long as users need to opt into deprecation warnings explicitly, that is ok
as well (and would be a “staging" and “production" setup, in practice).

73 matches

Mail list logo