> . 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. ------- Jean-Michaël Celerier http://www.jcelerier.name On Sun, Dec 3, 2017 at 5:41 PM, Alejandro Exojo via Development < development@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
