C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Labelled parameters

From: Thiago Macieira <thiago_at_[hidden]>
Date: Tue, 06 Jan 2026 21:35:08 -0300
On Tuesday, 6 January 2026 19:21:49 Brasilia Standard Time Barry Revzin wrote:
> In theory, we have modules. In practice, we have #pragma
> push_macro/pop_macro — which are a bit tedious to use since it takes 3
> lines of code per macro name, but it is at least possible to temporarily
> undefine a macro if a library author really wants to be friendly.
>
> Also there's relevant history here. In C++20, we added two new types which
> had a public member function (not parameter) named emit, which obviously
> conflicts with Qt's macro as you're pointing out. But LWG3399 (
> https://cplusplus.github.io/LWG/issue3399) was decided to be not a defect,
> and the name stayed (e.g.
> https://eel.is/c++draft/syncstream.syncbuf.members). For what it's worth,
> that vote wasn't close either (2 in favor of renaming emit, 28 opposed).

At least in Qt's case, we have a way to turn off those lowercase macros and the
majority of generic libraries using Qt (including Qt itself) don't use those
in public headers, so one can centrally fix it.

I don't see ncurses or Win32 (even in "lean and mean mode") ever fixing
themselves. And like the #pragma once case, the problem is not going to show
up when the library maintainers are developing their libraries, but when
someone else merges two libraries together in a third project, producing hard-
to-understand errors.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel Data Center - Platform & Sys. Eng.

Received on 2026-01-07 00:35:17