>> . 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@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 -- Regards, Konstantin _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
