Document number: P1697R0
Date: 2019-06-11
Project: Programming Language C++
Audience: Core Working Group
Reply-to: Botond Ballo

Require a diagnostic for "declaration changes meaning"

Abstract

This paper proposes to require a diagnostic for (some) violations of [basic.scope.class] p1.2 (where a declaration in a class scope changes the meaning of a name used earlier in that class scope).

Issue Description

Originally posted in core/2016/09/0932.

The following code:

struct foo {}; struct bar { foo* m_foo; foo* foo() { return m_foo; } };

is ill-formed, due to [basic.scope.class] p1.2: "A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule."

gcc and clang differ on whether they issue a diagnostic for this code. clang does not, but gcc does:

test.cpp:6:30: error: declaration of `foo* bar::foo()' [-fpermissive] foo* foo() { return m_foo; } ^ test.cpp:1:8: error: changes meaning of `foo' from `struct foo' [-fpermissive] struct foo {}; ^

A number of C++ developers have complained to me about this, and I've been bitten by it myself. Usually it happens in the following way:

It could be argued that this is just a QoI issue with clang, but I'm wondering if there's any good reason for the standard not to require a diagnostic in cases like this.

I've brought this up during informal discussion in June 2016 (Oulu), and several implementers have told me they don't see a problem with requiring a diagnostic in cases like this.

Proposed Resolution

The following is a strawman proposed resolution:


Modify [basic.scope.class] p1.2 as follows:

A name N used in a class S shall refer to the same declaration in its context and when re-evaluated in the completed scope of S. No diagnostic is required for a violation of this rule.


I describe this as a strawman resolution because I figure that a blanket requirement for diagnosing all violations of this rule may be a burden to implement. I expect a viable resolution will likely involve identifying a subset of violations of this rule (including at least cases similar to the example above) which are diagnosable without too much implementation burden, and requiring a diagnostic only for that subset. I am hoping for some guidance as to what that subset may be.