On Tue, 25 Feb 2020 at 21:37, Matthew Woehlke <mwoehlke.fl...@gmail.com> wrote: > > On 24/02/2020 07.34, Edward Welbourne wrote: > > Mitch Curtis (24 February 2020 13:22) > >> I don't think anyone has explained what that harm is yet. > > > > #define emit > > > > causes problems when you import a header that declares > > > > void emit(Type arg); > > > > and the compiler sees > > > > void (Type arg); > > > > and throws a wobbly. > > - Until now, `emit` has rarely been used in code that needs to mix with Qt. > > - C++20 will have modules. > > - Modules are theoretically immune to the above issue.
Module definitions are immune to macros affecting what they export, but client code is not immune to mixtures of module imports and header includes when the latter defines a macro. If you import a Std.IOStream module and then include QObject, you can't call std::osyncstream::emit(). > Where, exactly, is the problem? It seems to me we are making a big deal > out of something that will *still* only be a problem when mixing Qt > (with no QT_NO_KEYWORDS) and *certain uses* of <osyncstream>. Correct. > This doesn't seem appreciably different from the existing situation with > boost::signals. Ergo, I am confused why we are all acting like the sky > is falling? Indeed. > Maybe we should, at least, take a step back and wait to see if this > *actually affects many people* before worrying about it? Seems reasonable. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
