[Development] Basing Qt Creator Coding Style on C++ Core Guidelines?

[Marc Mutz]

On 2016-11-18 20:37, Marc Mutz wrote:
> On Friday 18 November 2016 09:30:03 Lars Knoll wrote:
>> On 17/11/16 23:03, Thiago Macieira wrote:
[...]
>> >    But GSL is another story. If it is sensibly developed, with a promise
>> >    to binary compatibility for extended periods of time and no nonsense
>> >    stuff like inline namespaces, we could accept it. Especially the
>> >    header-only parts of it.
[...]
>> Let's wait a bit how this develops, and whether they are even 
>> interested in
>> keeping compatibility between versions. But it would be another
>> dependency, something I don't want to introduce without getting enough
>> benefit out of it.
> 
> The GSL is header-only. There are no BC guarantees, and, "worse", there 
> are
> different implementations. All the compiler, or a static checker, cares 
> about
> is the name of type: ::gsl::owner, ::gsl::non_null, ::gsl::string_span. 
> It
> does not care about the implementation.

To see how simple gsl::owner markup is to incorporate into Qt, I sat 
down, added it to QtGlobal and marked up QScopedPointer (incl. docs) 
with gsl::owner.

https://codereview.qt-project.org/178107

Anything other than gsl::owner is hitting the incompatibility wall, but, 
given some form of reliable detection of GSL alternatives, could be used 
with a Qt implementation as a fallback. In that case, Qt would only give 
BC guarantees for the version compiled with its own version of the GSL. 
This is a stop-gap measure to enable the use of more of GSL in Qt while 
still being bound by the current restrictive API rules. Personally, I 
wouldn't bother with anything but gsl::owner until those rules are 
relaxed to allow upstream GSL's types in the ABI.

The use of gsl::owner now also marks places where we might want to use 
unique_ptr in the future, reducing this amount of conceptual work when 
moving to Qt 6.

Thanks,
Marc