[Development] QtCS 2017 QtCore sessions

Marc Mutz marc.mutz at kdab.com
Thu Nov 30 15:02:19 CET 2017


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[]!

> * 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.

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().

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.

Thanks,
Marc

[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.
[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




More information about the Development mailing list