On quinta-feira, 30 de novembro de 2017 06:02:19 PST Marc Mutz wrote: > On 2017-10-10 14:49, Thiago Macieira wrote: > [...] > > > * We think members are cleaner and we don't want to add these > > You have members where members are possible. > But you can't add members to char16_t[]!
Why would we need to? > > * However, we already have some of those! qStartsWith > > ** Global namespace *and* documented > > ** foo.startsWith(bar) vs qStartsWith(foo, bar) > > ** Same conclusion, probably mark \internal, namespace them > > *** But review the changes to see what our arguments were on making > > them > > public > > I have seen that you used my recent absence to sneak in a change to put > these functions into the QtPrivate namespace - in a public header! It's > good that you agree that there should be free functions for them, it's a > pity that you think you need to hide them. I did not know you were absent when this was posted. Sorry, we cannot be held to blame for your employer deciding to suspend participation for a while. Qt development did not stop. You'll note I had agreed with you when those functions came in. It was during the QtCore session at QtCS that when I brought them up, people cringed and asked whether it was the Qt-way. The conclusion was it wasn't, so I posted here *and* in the API review that we were going to change. > No-one forces anyone to use them, but they are there for when you need > them: for use in generic code, to have one syntax that works for every > pair of arguments[1]. People are still free to use vec.begin(), and > personally, I'll choose that every time over std::begin(vec), but > std::begin() needs to be there, too. Same thing for qCompareStrings(). We just didn't want to make them officially part of the API. > I will not restart work on QStringView before these are put back. So, > please, restore them to the state they had[2], then I'll get approval > for finishing the work on QStringView. If it's too late for 5.10, add > them back as inline functions, calling the useless QtPrivate ones, > please. It's too late for 5.10, but we can add them as inline functions for 5.11, if there's strong reason. I don't believe there is. The reason is still the same: we don't want them in the API. > [1] e.g., at some point, we should make operator==(string-like, > string-like) templated and just call qCompareStrings. There's no reason > to hold this API from the user. What's wrong with str.compare()? > [2] incl., btw, the constexpr on QStringView(Char*), which is required > for std::string_view compat: > http://en.cppreference.com/w/cpp/string/basic_string_view/basic_string_view Pity. Performance is more important than constexpr. This stays until C++ allows us to overload constexpr and non-constexpr. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
