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: