On Tue, 25 Feb 2020 at 22:17, Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote: > Right, and when I realized that, it got me wondering, how many people > will need to call that specific function that are *also* using Qt *and* > will be unwilling to use Q_NO_KEYWORDS to work around the issue?
You're getting back to the reason why renaming osyncstream::emit() was unconvincing, here. ;) But the reason why we are talking about this is to search for a solution where such clashes don't happen in the future. Yes, we know how to deal with boost::signals, yes, we know how to deal with X11 Status clashing with QSettings::Status, but maybe we shouldn't have to deal with these clashes that are our own doing because it's us defining the problematic macros. (In the X11 case, it's X11, not us.) We could be better-behaving citizens of the ecosystem, instead of saying "well we've been bad citizens for a long time, please just accommodate us, here's hacks that allow you to circumvent the problems we cause". _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development