This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

2642. [filesys.ts] [PDTS] class path should have defaulted constructors/destructor/assignments.

Section: 8 [filesys.ts::class.path] Status: NAD Submitter: P.J. Plauger Opened: 2014-01-30 Last modified: 2016-08-12

Priority: Not Prioritized

View all other issues in [filesys.ts::class.path].

View all issues with NAD status.

Discussion:

Addresses: filesys.ts

class path should have defaulted constructors/destructor/assignments.

[2014-02-26 Beman Dawes comments]

Suggest NAD. Earlier versions did have defaulted constructors/destructor/assignments, but they were removed at the request of Alberto Ganesh Barbati (c++std-filesys January 8, 2013):

Speaking of =default, we have to be careful not over-constrain the specification. I mean, if we just specify the intended meaning of those function with proper wording, the implementation is allowed to use =default in case it provides an equivalent behaviour, but if we put =default in the specification, the implementation is required to use it. However, we have to remember that "for exposition only" data members may not be an exhaustive list and that 17.5.2.3/2 allows implementations to provide an equivalent behaviour using different members for which "default" construction/copy/assignment may not be appropriate.

=default is what we want for tuple, atomics, etc. It might be appropriate for simple types like file_status, but, for more complex types like path itself, I'd remove it and add proper wording.

[17 Jun 2014 Rapperswil LWG closes as NAD. Ganesh's analysis is correct. WP correct as written.]

Proposed resolution: