On 2019-06-11 09:48, Lars Knoll wrote:
On 11 Jun 2019, at 09:35, Olivier Goffart <oliv...@woboq.com> wrote:
On 11.06.19 09:17, Lars Knoll wrote:
So, is removing it worth all the hassle to us and our users?
Q_FOREACH is a macro and it doesn’t really cost us anything to keep
it around. Yes, it has issues with non Qt containers and I wouldn’t
recommend it for any new code. But maybe we could simply fix that
part, but making Q_FOREACH emit a compiler warning if used on a
container that’s not implicitly shared?
+1
Although we should probably still discourage its usage in the
documentation.
Regarding the compiler warning:
https://codereview.qt-project.org/c/qt/qtbase/+/244010
Nice. So doesn’t this solve most of the issues we have with Q_FOREACH
(maybe with the exception that some people find macros ugly)?
If you look at the git history, you will find that it's not at all
maintenance-free code that just sits there. I just saw a C++17(!)-only
code path there when I rebased my deprecation patch to current dev the
other day.
There's also, as Peppe has repeatedly indicated (and never got a proper
reply to) the teaching/documentation issue: as long as Q_FOREACH stays,
undeprecated, we need to teach people about it: when to use and when not
to use. That's usually 10min or so of an intro Qt course that could be
better spent on teaching something more important.
If Q_FOREACH is deprecated, we can drop the slides, and a good chunk of
the docs.
This is a bit like the Fridays for Future generation clash: the new
developer asks "why is there Q_FOREACH if there's ranged-for?" and the
older devs answer: "because I wants my SUV, erhm, I mean Q_FOREACH".
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
