<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 4033: &sect;[macro.names] defining macros after importing the standard library</title>
<meta property="og:title" content="Issue 4033: &sect;[macro.names] defining macros after importing the standard library">
<meta property="og:description" content="C++ library issue. Status: New">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue4033.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#New">New</a> status.</em></p>
<h3 id="4033"><a href="lwg-active.html#4033">4033</a>. &sect;[macro.names] defining macros after importing the standard library</h3>
<p><b>Section:</b> 16.4.5.3.3 <a href="https://wg21.link/macro.names">[macro.names]</a> <b>Status:</b> <a href="lwg-active.html#New">New</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2023-12-27 <b>Last modified:</b> 2024-08-02</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#macro.names">active issues</a> in [macro.names].</p>
<p><b>View all other</b> <a href="lwg-index.html#macro.names">issues</a> in [macro.names].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#New">New</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are several places where the standard talks about what happens when including
a header, and only sometimes do we address the notion of importing a header unit, or
importing a standard library module.

One global concern is that 16.4.5.3.3 <a href="https://wg21.link/macro.names">[macro.names]</a> prohibits users defining macros with a name
that matches a name from any standard library header, but only if a standard library header
is included. We should maintain that same prohibition on importing a standard header unit,
and importing a standard library module.

In general, we probably want some front matter to address the include vs. import wording
issue in one place, rather than trying to update every usage &mdash; if it is already there I could
not find it. It is also likely that some uses will want to say specific things about import vs.
include and those cases will be handed to audit for if we have blanket front-matter wording.

I also question whether "shall not" is the right way to prohibit users defining macros in their
own code. Must a "shall not" restriction be diagnosed? I think the "right" answer is to make
the program ill-formed, no diagnostic required. That is a foul answer, but UB does not really
fit as there is no actual behavior to be undefined, unless we mean the process of translating
the program is undefined, in which case IFNDR is the better way to say that.

If we expect implementations to diagnose users defining macros that match library names we
should say so more clearly, but I am not aware of any current tool-chain that does so.
</p>

<p><i>[2024-08-02; Reflector poll]</i></p>

<p>
Set priority to 3 after reflector poll.
"Why should <code class='backtick'>import std</code> care if I <code class='backtick'>#define vector potato</code>?"
</p>



<p id="res-4033"><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="https://wg21.link/N4971" title=" Working Draft, Programming Languages — C++">N4971</a>.
</p>

<ol>

<li><p>Modify 16.4.5.3.3 <a href="https://wg21.link/macro.names">[macro.names]</a> as indicated:</p>

<blockquote>
<p>
-1- <ins>If a translation unit includes a standard header, imports a standard header unit, or imports a
standard library module, and provides a name specified in the standard library as an argument to <code>#define</code> 
or <code>#undef</code>, the program is ill-formed, no diagnostic required</ins><del>A translation unit that includes 
a standard library header shall not <code>#define</code> or <code>#undef</code> names declared in any standard library header</del>.
<p/>
-2- A translation unit shall not <code>#define</code> or <code>#undef</code> names lexically identical to keywords, to the identifiers 
listed in Table [tab:lex.name.special], or to the <i>attribute-token</i>s described in 9.13 <a href="https://wg21.link/dcl.attr">[dcl.attr]</a>, except that 
the names <code>likely</code> and <code>unlikely</code> may be defined as function-like macros (15.7 <a href="https://wg21.link/cpp.replace">[cpp.replace]</a>).
</p>
</blockquote>

</li>

</ol>







</body>
</html>
