LWG 2259 relaxes requirements, perhaps unintentionally
Ville Voutilainen

Created on 2015-11-29.00:00:00, last changed 2018-11-12.05:21:03.


Date: 2018-11-12.05:21:03

[ 2018-11 San Diego Thursday night issue processing ]

Status to NAD

Date: 2018-08-24.13:31:33

[ 2018-08 Batavia Monday issue discussion ]

Ville recommends NAD; because closing this would outlaw conforming extensions.

Date: 2018-08-22.12:55:05

[ 2018-08 Batavia Monday issue discussion ]

Ville to provide wording.

Date: 2017-02-02.00:41:18

[ 2016-05 Issues Telecon ]

This is related to issue 2695.

Date: 2016-04-16.04:56:37

[ 2016-04, Issues Telecon ]

Ville provides a motivating example.

#include <iostream>

class my_stream : std::ostream

int main()
    my_stream ms;

This example is accepted by libstdc++, msvc rejects it, and clang+libc++ segfault on melpon.org/wandbox o_O. An earlier clang+libc++ just accepts it. I don't think the implementation divergence is caused by the acceptance of the referred-to 2259, but it certainly seems to increasingly bless the implementation divergence.

Date: 2015-11-29.00:00:00

The combination of [member.functions], paragraphs 2 and 3 that LWG 2259 does seems to drop a requirement that any call behaves as if no overloads were added. Paragraph 3 used to say "A call to a member function signature described in the C ++ standard library behaves as if the implementation declares no additional member function signatures." whereas the new wording says "provided that any call to the member function that would select an overload from the set of declarations described in this standard behaves as if that overload were selected."

This can be read as meaning that if there's no default constructor specified, like for instance for std::ostream, an implementation is free to add it. It can also be read as meaning that an implementation is free to add any overloads that wouldn't change the overload resolution result of any call expression that would select a specified overload. That's vastly different from allowing extensions that add new functions rather than new overloads.

Was this relaxation intentional?

Date User Action Args
2018-11-12 05:21:03adminsetmessages: + msg10211
2018-11-12 05:21:03adminsetstatus: new -> nad
2018-08-24 13:31:33adminsetmessages: + msg10114
2018-08-22 12:55:05adminsetmessages: + msg10091
2016-05-22 15:38:38adminsetmessages: + msg8132
2016-04-16 04:56:37adminsetmessages: + msg8059
2015-11-29 00:00:00admincreate