On Freitag, 4. November 2022 21:47:14 CET Thiago Macieira wrote:
> On Friday, 4 November 2022 10:38:30 PDT Allan Sandfeld Jensen wrote:
> > Can we even do that, and still preserve ABI and API?
>
> I don't see why not. QFlags is already standard-layout, trivially copyable
> and trivially
On Friday, 4 November 2022 10:38:30 PDT Allan Sandfeld Jensen wrote:
> Can we even do that, and still preserve ABI and API?
I don't see why not. QFlags is already standard-layout, trivially copyable and
trivially destructible. Changing the member from private to public won't affect
any of those
On Freitag, 4. November 2022 16:49:30 CET Thiago Macieira wrote:
> I've just hit this: should we make some of our very simple types even
> simpler so they're structural types[1] and thus can be passed as template
> parameters?
>
> For example, QFlags. I've just tried it and I get:
>
> error:
I've just hit this: should we make some of our very simple types even simpler
so they're structural types[1] and thus can be passed as template parameters?
For example, QFlags. I've just tried it and I get:
error: ‘QFlags’ is not a valid type for a template non-type
parameter because it is not
Hi Ulf,
On 04.11.22 12:13, Ulf Hermann via Development wrote:
> One thing I haven't understood about the ordering problem is why we
> cannot just define our "invalid" values to always be < any valid one and
> equal to other invalid ones. This way we get at least weak ordering for
> all our
Hi,
After getting my head washed by Volker, lemme provide background on
these two functions.
TL;DR: we created real maintenance and porting problems by not removing
stop-gap functionality in a timely fashion, qNN presented as a way to
ensure this won't happen again.
Both qAsConst and
Once we had QString and QByteArray (and the admittedly ill-conceived
QStringRef). Now we have QStringView, QAnyStringView, QByteArrayView,
... and when asking what the prefered getter/setter-signature for
"Qt-style" interfaces is the answer I get is "We'd guess $X, but the
only guy that knows for
On Wed, Nov 02, 2022 at 02:25:25PM +, Marc Mutz via Development wrote:
> Hi Volker,
>
> On 14.10.22 17:12, Volker Hilsheimer via Development wrote:
> > Anyway, I’ve added the respective text to the coding convention wiki
> > page.
> > https://wiki.qt.io/Coding_Conventions
>
> Having read
Hi,
One thing I haven't understood about the ordering problem is why we
cannot just define our "invalid" values to always be < any valid one and
equal to other invalid ones. This way we get at least weak ordering for
all our types and we're done.
There may be types where existing operator<
On Thursday, 3 November 2022 09:48:49 PDT Marc Mutz via Development wrote:
>>> Here, too, I feel lost. I'm struggling to see what a NIH
>>> std::partial_ordering w/o the weak and strong counterparts and w/o
>>> op<=> language support could achieve, except another vocabulary type
>>> mismatch. Can
Hi Thiago,
On 03.11.22 18:38, Thiago Macieira wrote:
> On Thursday, 3 November 2022 09:48:49 PDT Marc Mutz via Development wrote:
>> On 03.11.22 16:17, Thiago Macieira wrote:
>>> For some classes, we could postpone changing anything until C++20 is
>>> required.
>> You lost me there. Why do you
+1
Unsurprisingly, I'm part of the same team as Sami
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Hi,
I'd like to nominate Sami Shalayel as an approver for the Qt project.
Sami is employed by the Qt Company and has been working since May on Qt, mostly
on QtDeclarative, with a focus on qmltc.
He made several good contributions there, and also participates in the review
process of QML related
13 matches
Mail list logo
