Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On 08.11.23 16:46, Thiago Macieira wrote: > On Wednesday, 8 November 2023 00:38:32 PST Marc Mutz via Development wrote: >> Let's not mix up topics here... >> >> 1/ We're not responsible for the ABI of third-party libraries. As long as >> we document that the return type of a non-exported inline fun

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 8 November 2023 10:05:38 PST Ivan Solovev via Development wrote: > > I think it's acceptable for us to change the return type of a function so > > long as it's getting a new mangling. > > Well, it would be easily achievable for the template methods, but not for > the inline hidden fr

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

> I think it's acceptable for us to change the return type of a function so long > as it's getting a new mangling. Well, it would be easily achievable for the template methods, but not for the inline hidden friend helper methods. As immediate solution that comes to my mind is to add a third argume

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

On Wednesday, 8 November 2023 00:38:32 PST Marc Mutz via Development wrote: > Let's not mix up topics here... > > 1/ We're not responsible for the ABI of third-party libraries. As long as > we document that the return type of a non-exported inline functions > changes, then it's SEP if someone else

Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers

On Monday, 6 November 2023 06:55:25 PST Alex Blasche via Development wrote: > I'd like to nominate Tatiana Borisova as maintainer for Qt Protobuf and > Alexey Edelev as maintainer for Qt GRPC. In fact, both have been working on > this code base even before they officially became part of Qt. I am gl

Re: [Development] Nominating Jaishree Vyas as approver

+1 -- Ivan Solovev Senior Software Engineer The Qt Company GmbH Erich-Thilo-Str. 10 12489 Berlin, Germany ivan.solo...@qt.io www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenbur

Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers

I'd like to nominate Tatiana Borisova as maintainer for Qt Protobuf and Alexey Edelev as maintainer for Qt GRPC. In fact, both have been working on this code base even before they officially became part of Qt. I am glad they agreed to continue this work going forward in the context of Qt Developme

Re: [Development] Nominating QtGRPC & Qt Protobuf maintainers

+1 Disclaimer: Tatiana is in the same team as myself; Alexey is a colleague at TQtC. On 06.11.23 15:55, Alex Blasche via Development wrote: > Hi, > > Qt GRPC and Qt Protobuf were added to Qt a while ago. However until now they > have been in Tech Preview mode. As we investigate the remaining i

Re: [Development] Nominating Jaishree Vyas as approver

+1 Disclaimer: we're in the same team at TQtC... On 08.11.23 10:00, Paul Wicking via Development wrote: > Hi everyone, > > I would like to nominate Jaishree Vyas for approver rights in the Qt > project. > > Jai has joined TQtC as a Documentation Engineer back in February 2022. > Since then, s

Re: [Development] Nominating Jaishree Vyas as approver

Hi, Jaishree is reviewing documentation for QtGrpc and QtProtobuf modules and I'm happy to give mine +1 here. Alexey Alexey Edelev Software Engineer Qt Group Erich-Thilo-Str. 10 12489 Berlin, Germany alexey.ede...@qt.io www.qt.io [https://s3.eu-north-1.amazonaws.com/ema

[Development] Nominating Jaishree Vyas as approver

Hi everyone, I would like to nominate Jaishree Vyas for approver rights in the Qt project. Jai has joined TQtC as a Documentation Engineer back in February 2022. Since then, she's been actively making and reviewing changes. I fully trust Jai's judgment in reviewing and approving changes, and se

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

Let's not mix up topics here... 1/ We're not responsible for the ABI of third-party libraries. As long as we document that the return type of a non-exported inline functions changes, then it's SEP if someone else writes code that ties their ABI to the result type of such functions. We're only