On 22 Jul 2020, at 00:14, Ville Voutilainen <ville.voutilai...@gmail.com<mailto:ville.voutilai...@gmail.com>> wrote:
On Wed, 22 Jul 2020 at 00:18, Volker Hilsheimer <volker.hilshei...@qt.io<mailto:volker.hilshei...@qt.io>> wrote: With the current design, notational convenience doesn’t work either: auto text = qAction->text; text.left(10); // booh ‘text’ is not a QString, but a QAction::_qt_property_api_text object, with broken... everythings. And if people can’t use auto, then you can’t use standard ranged-for to iterate over container type properties without spelling everyhing out. That’s ... not convenient, I suppose. And that problem persists, even if we expose a e.g QProperty<QStringList> reference through a public property member. Couldn't we add operator-> and begin/end to the property type? Yes, there are ways to solve at least part of those issues. Using auto together with those properties is something to consider. But I don’t think we should throw away the whole concept because of it. We can partly solve it by e.g. making the properties not copyable. And we do have similar problems other places (and so does the STL btw). We e.g. need qAsConst() when using our containers with ranged-for our containers. But IMO that is no reason to throw the baby out with the bath-tub water. The current implementation also adds, in case of us not being able to use no_unique_address, a byte or even a pointer to each class in a class hierarchy, bloating classes down in the inheritance tree. Plus the BC challenge that might come with in the long run. So, this is not only a problem of UB. There is well defined behavior that seems to get in the way. Ack. no_unique_address is coming and making that problem go away. It’s available on all compilers except MSVC today (see https://en.cppreference.com/w/cpp/compiler_support#cpp2a). We want things to work on C++17 and that’s what we have. But we can and should plan for C++20. Cheers, Lars
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
