[Development] QProperty and library coding guide

[Lars Knoll]

> On 21 Jul 2020, at 22:51, Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
> 
> On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
> <ville.voutilainen at gmail.com> wrote:
>> 
>> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira <thiago.macieira at intel.com> wrote:
>>> 
>>> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
>>>> A very significant goal of this exercise is achieving notational
>>>> convenience. Theoretical concerns about UB
>>>> in the presence of papers that apparently excise that UB shouldn't
>>>> stand in the way of that goal.
>>> 
>>> Sorry, I don't agree. We can't use something that is unimplementable.
>> 
>> Oh, when did that change? Was qobject_cast changed not to be UB?
> 
> See also all the memcpys that are done with types that are
> polymorphic, and the ones
> where we memcpy types that have user-provided copy operations. qtbase
> is UB left right
> and center, but it's certainly interesting that when a new thing in it
> might be clarified
> not to be UB after all, we perform all kinds of somersaults to avoid
> such dark corners.

+1. Movable types are UB, still we do not want to sacrifice those, as they give a huge performance benefit, esp. for. Refcounted shared types.

We now have something where we aim for API equivalence between an API we can offer our users and the additional jumps we have to do to achieve the same thing while hiding our data (purely because we want to offer BC). API equivalence is extremely important if we want this to work. The current implementation has a bit of UB in it that does work on all current compilers. It’s not inline in user code, so if a new compiler comes up that requires fixing this using e.g. inline assembly we can still do this (as taking the new compiler into use requires a recompile anyway). 

So I don’t really see where we have a huge problem with the current design that is not solvable without sacrificing it.

Cheers,
Lars