On 31 May 2023, at 16:05, Thiago Macieira <thiago.macie...@intel.com> wrote:
On Wednesday, 31 May 2023 00:17:21 PDT Marc Mutz via Development wrote: I doubt there's an accepted project-wide standard, yet, but as a rule of thumb that everyone might be able to agree on: If the function doesn't store the string as-is (=parses or pre-processes it), take by QAnyStringView, otherwise continue to take by QString cref. I want to be very clear on that: the function's *purpose* must be to parse the string in question and act on it immediately. It shouldn't be about what the implementation is currently, but about what the function is. This is as clear a guideline as it gets, IMHO. Attempts to clarify this further by example or e.g. using the function's name as a guideline, are IMHO rather making it less clear. It’s either way a rule of thumb that will give the correct API in the vast majority of cases. For the corner cases, we have code, API, and header reviews (*). Added the essence to https://wiki.qt.io/API_Design_Principles. The comments about overloads, taking addresses of Qt entities, or explicitly specifying deducible template parameters are all valid, also outside the specific question. Volker (*) which would benefit from more eyeballs at https://codereview.qt-project.org/q/topic:api-change-review-6.6
-- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
