Bug 60284 - [DR 253] Default-initialization without user-provided constructor allowed
Summary: [DR 253] Default-initialization without user-provided constructor allowed
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 4.9.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: accepts-invalid
Depends on:
Blocks: c++-core-issues
  Show dependency tree / graph
 
Reported: 2014-02-20 08:52 UTC by David Krauss
Modified: 2024-04-04 00:21 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-02-20 00:00:00

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description David Krauss 2014-02-20 08:52:29 UTC 
This declaration is ill-formed according to the last sentence of [dcl.init] §8.5/7, "If a program calls for the default initialization of an object of a const-qualified type T, T shall be a class type with a user-provided default constructor":

struct a {} const o;

There is actually a very nice diagnostic implemented by r179170 and PR42844, but it's only activated when the class has an uninitialized member, per the notes of CWG DR 253. However those notes aren't normative and Clang diagnoses the error, http://stackoverflow.com/q/21900237/153285 .
Comment 1 Jonathan Wakely 2014-02-20 09:20:35 UTC 
This is by design, because as DR 253 shows, the normative standard is flawed.
Comment 2 Andrew Pinski 2024-04-04 00:20:21 UTC 
From cwg253 (https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#253):
[Adopted at the November, 2016 meeting as part of paper P0490R0.]


But I can't tell if it was a adopted as a defect report or just implemented as part of C++17.