[Development] QtCS 2017 QtCore sessions

[Konstantin Tokarev]

>> . I would be fine having the same developer experience in C++
> 
> even if I had to change name spaces and includes, but doesn't seem usual
> 
> practice in C++.
> 
> uh... ? I have been polyfilling optional, string_view, any, and variant for almost three years with boost, or std/experimental/. The API is 99% compatible to what's in std.

FWIW, WebKit project is also doing this for years (by importing experimental implementations into the source tree)

> 
> -------
> Jean-Michaël Celerierhttp://www.jcelerier.name
> 
> On Sun, Dec 3, 2017 at 5:41 PM, Alejandro Exojo via Development <development at qt-project.org> wrote:
> 
>> On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote:
>>
>>> > > And, c'mon, std::optional's API is just not going to be topped by
>>
>>> > > QOptional. What should they do? snake_case vs. camelCase? That's what
>>
>>> > > we need to invest several man-days of development work in, to rename
>>
>>> > > the functions and stick a Q in front of the class name?
>>
>>> >
>>
>>> > There's one thing that a QOptional could do that std::optional can't:
>>
>>> > be available for all Qt users
>>
>>> > in a time span of a couple of months.
>>
>> True. And that, in my very humble opinion, highlights a common problem that
>>
>> people face in projects in all languages: wanting to use a standard
>>
>> functionality that is not yet available in the platforms that you have to
>>
>> support. Many other languages are able to "polyfill"/shim not-yet-standardized
>>
>> classes or functions (even members) in a clean way, by adding a 3rd party
>>
>> library and done. I would be fine having the same developer experience in C++
>>
>> even if I had to change name spaces and includes, but doesn't seem usual
>>
>> practice in C++.
>>
>>> And another thing: be properly documented in a way that people who
>>
>>> are not CS phd's can understand. std completely and utterly fails
>>
>>> in that. Parts of Qt's docs are bad enough, but there's nothing in
>>
>>> cppreference.com that would pass muster for my gsoc students.
>>
>> I wholeheartedly agree. I understand the argument of the lambda in find_if in a
>>
>> somewhat intuitive way, but the explanations that one finds there about it are
>>
>> hugely discouraging to me (full of standardese), even if it's been some years
>>
>> using C++. It's not rare to see pages documenting a class or function, that,
>>
>> instead of giving examples of its usage, show instead three possible
>>
>> implementations. When you are trying to understand how it's used, or why it's
>>
>> useful. :-(
>>
>> And a 3rd point, that not necessarily applies to QOptional if everything is
>>
>> templated and inline, but I think still the main blocker for using more
>>
>> standard API is the lack of ABI stability. Yes, that's misfeature for some,
>>
>> but it's the current rule, so ignoring it is not helping the conversation,
>>
>> IMHO.
>>
>> --
>>
>> Viking Software, Qt and C++ developers for hire
>>
>> http://www.vikingsoftware.com
>>
>> _______________________________________________
>>
>> Development mailing list
>>
>> Development at qt-project.org
>>
>> http://lists.qt-project.org/mailman/listinfo/development
-- 
Regards,
Konstantin