Section: 16 [library] Status: C++11 Submitter: Daniel Krügler Opened: 2009-08-18 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [library].
View all other issues in [library].
View all issues with C++11 status.
Discussion:
Several parts of the library use the notion of "Diagnostic required" to indicate that in the corresponding situation an error diagnostic should occur, e.g. 20.3.1.2.2 [unique.ptr.dltr.dflt]/2
void operator()(T *ptr) const;Effects: calls
deleteonptr. A diagnostic is required ifTis an incomplete type.
The problem with this approach is that such a requirement is insufficient to prevent undefined behavior, if this situation occurs. According to 3.17 [defns.diagnostic] a diagnostic message is defined as
a message belonging to an implementation-defined subset of the implementation's output messages.
which doesn't indicate any relation to an ill-formed program. In fact, "compiler warnings" are a typical expression of such diagnostics. This means that above wording can be interpreted by compiler writers that they satisfy the requirements of the standard if they just produce such a "warning", if the compiler happens to compile code like this:
#include <memory>
struct Ukn; // defined somewhere else
Ukn* create_ukn(); // defined somewhere else
int main() {
std::default_delete<Ukn>()(create_ukn());
}
In this and other examples discussed here it was the authors intent to guarantee that the program is ill-formed with a required diagnostic, therefore such wording should be used instead. According to the general rules outlined in 4.1 [intro.compliance] it should be sufficient to require that these situations produce an ill-formed program and the "diagnostic required" part should be implied. The proposed resolution also suggests to remove several redundant wording of "Diagnostics required" to ensure that the absence of such saying does not cause a misleading interpretation.
[ 2009 Santa Cruz: ]
Move to NAD.
It's not clear that there's any important difference between "ill-formed" and "diagnostic required". From 4.1 [intro.compliance], 3.25 [defns.ill.formed], and 3.66 [defns.well.formed] it appears that an ill-formed program is one that is not correctly constructed according to the syntax rules and diagnosable semantic rules, which means that... "a conforming implementation shall issue at least one diagnostic message." The author's intent seems to be that we should be requiring a fatal error instead of a mere warning, but the standard just doesn't have language to express that distinction. The strongest thing we can ever require is a "diagnostic".
The proposed rewording may be a clearer way of expressing the same thing that the WP already says, but such a rewording is editorial.
[ 2009 Santa Cruz: ]
Considered again. Group disagrees that the change is technical, but likes it editorially. Moved to NAD Editorial.
[ 2009-11-19: Moved from NAD Editorial to Open. Please see the thread starting with Message c++std-lib-25916. ]
[ 2009-11-20 Daniel updated wording. ]
The following resolution differs from the previous one by avoiding the unusual and misleading term "shall be ill-formed", which does also not follow the core language style. This resolution has the advantage of a minimum impact on the current wording, but I would like to mention that a more intrusive solution might be preferrable - at least as a long-term solution: Jens Maurer suggested the following approach to get rid of the usage of the term "ill-formed" from the library by introducing a new category to existing elements to the list of 16.3.2.4 [structure.specifications]/3, e.g. "type requirements" or "static constraints" that define conditions that can be checked during compile-time and any violation would make the program ill-formed. As an example, the currently existing phrase 22.4.7 [tuple.helper]/1
Requires:
I < sizeof...(Types). The program is ill-formed ifIis out of bounds.could then be written as
Static constraints:
I < sizeof...(Types).
[ 2009-11-21 Daniel updated wording. ]
[ 2009-11-22 Moved to Tentatively Ready after 5 positive votes on c++std-lib. ]
Proposed resolution:
Change 21.4 [ratio]/2 as indicated:
Throughout this subclause, if the template argument types
R1andR2shall beare not specializations of theratiotemplate, the program is ill-formed.Diagnostic required.
Change 21.4.3 [ratio.ratio]/1 as indicated:
If tThe template argument D shall not
be is zero, and or the absolute values of
the template arguments N and D shall be are
not representable by type intmax_t, the program is
ill-formed. Diagnostic required. [..]
Change 21.4.4 [ratio.arithmetic]/1 as indicated:
Implementations may use other algorithms to compute these values. If overflow occurs, the program is ill-formed
a diagnostic shall be issued.
Change 21.4.5 [ratio.comparison]/2 as indicated:
[...] Implementations may use other algorithms to compute this relationship to avoid overflow. If overflow occurs, the program is ill-formed
a diagnostic is required.
Change 20.3.1.2.2 [unique.ptr.dltr.dflt]/2 as indicated:
Effects: calls
deleteonptr.A diagnostic is required ifTis an incomplete type.Remarks: If
Tis an incomplete type, the program is ill-formed.
Change 20.3.1.2.3 [unique.ptr.dltr.dflt1]/1 as indicated:
void operator()(T* ptr) const;Effects:
callsoperator()delete[]onptr.A diagnostic is required ifTis an incomplete type.Remarks: If
Tis an incomplete type, the program is ill-formed.
Change 20.3.1.3.2 [unique.ptr.single.ctor] as indicated: [Note: This editorially improves the currently suggested wording of 932 by replacing
"shall be ill-formed" by "is ill-formed"]
[If N3025 is accepted this bullet is applied identically in that paper as well.]
-1- Requires:
Dshall be default constructible, and that construction shall not throw an exception.Dshall not be a reference type or pointer type (diagnostic required)....
Remarks: If this constructor is instantiated with a pointer type or reference type for the template argument
D, the program is ill-formed.
Change 20.3.1.3.2 [unique.ptr.single.ctor]/8 as indicated: [Note: This editorially improves the currently suggested wording of 932 by replacing
"shall be ill-formed" by "is ill-formed"]
[If N3025 is accepted this bullet is applied identically in that paper as well.]
unique_ptr(pointer p);...
Remarks: If this constructor is instantiated with a pointer type or reference type for the template argument
D, the program is ill-formed.
Change 20.3.1.3.2 [unique.ptr.single.ctor]/13 as indicated:
[..] If
dis an rvalue, it will bind to the second constructor of this pair and the program is ill-formed.That constructor shall emit a diagnostic.[Note: The diagnostic could be implemented using astatic_assertwhich assures thatDis not a reference type. — end note] Elsedis an lvalue and will bind to the first constructor of this pair. [..]
Change 20.3.1.4 [unique.ptr.runtime]/1 as indicated:
A specialization for array types is provided with a slightly altered interface.
- Conversions among different types of
unique_ptr<T[], D>or to or from the non-array forms ofunique_ptrare disallowed (diagnostic required)produce an ill-formed program.- ...
Change 30.5 [time.duration]/2-4 as indicated:
2 Requires:
Repshall be an arithmetic type or a class emulating an arithmetic type.If a program instantiatesdurationwith adurationtype for the template argumentRepa diagnostic is required.3 Remarks: If
durationis instantiated with adurationtype for the template argumentRep, the program is ill-formed.
34RequiresRemarks: IfPeriodshall beis not a specialization ofratio,diagnostic requiredthe program is ill-formed.
45RequiresRemarks: IfPeriod::numshall beis not positive,diagnostic requiredthe program is ill-formed.
Change 30.6 [time.point]/2 as indicated:
If
Durationshall beis not an instance ofduration, the program is ill-formed.Diagnostic required.