Remove friend class from the library wording
#6427
Conversation
| class \tcode{directory_iterator}\iref{fs.class.directory.iterator} | ||
| is shown above as a friend of class \tcode{directory_entry}. | ||
| Friendship allows the \tcode{directory_iterator} implementation to cache | ||
| \tcode{directory_iterator} is allowed to cache |
There was a problem hiding this comment.
Are we allowed to say "allowed"?
Should this be turned into a "Recommended practice" note and say something like "Implementations of directory_iterator are encouraged to populate attributes of the directory_entry object upon construction, without calling refresh()"?
OTOH does this note actually mean anything at all? Implementations are always encouraged to omit "unneeded" code; we don't have to tell them that, do we?
| @@ -9222,7 +9222,6 @@ | |||
|
|
|||
| // bit reference | |||
| class @\libmember{reference}{vector<bool>}@ { | |||
| friend class vector; | |||
| constexpr reference() noexcept; | |||
There was a problem hiding this comment.
This private constructor declaration is probably observable because of something about SFINAE/overload-resolution. But I doubt that its constexpr and noexcept specifiers are observable.
(Similarly below, the fact that the copy ctor is =defaulted is unobservable, but perhaps it should be marked noexcept. Right now its noexceptness depends on the nothrow-copyability of this class's unseen data members.)
Same comments on bitset::reference below.
There was a problem hiding this comment.
So? This pull request is not about the private default constructor.
Fixes #5906.