Proposed resolution:

This wording is relative to N4917.

1. Modify [fs.op.weakly.canonical] as indicated:

   path filesystem::weakly_canonical(const path& p);
   path filesystem::weakly_canonical(const path& p, error_code& ec);
   

   -1- Effects: Using status(p) or status(p, ec), respectively, to determine existence, return a path composed by operator/= from the result of calling canonical() with a path argument composed of the leading elements of p that exist, if any, followed by the elements of p that do not exist, if any. For the first form, canonical() is called without an error_code argument. For the second form, canonical() is called with ec as an error_code argument, and path() is returned at the first error occurrence, if any.

   -2- Postconditions: The returned path is in normal form ([fs.path.generic]).

   -3- Returns: p with symlinks resolved and the result normalized ([fs.path.generic]).

   -4- Throws: As specified in [fs.err.report].

   -5- Remarks: Implementations should avoid unnecessary normalization such as when canonical has already been called on the entirety of p.

[ 2022-11-12 Approved at November 2022 meeting in Kona. Status changed: Immediate → WP. ]

[ Kona 2022-11-09; Move to Immediate ]

[ Kona 2022-11-07; LWG review ]

Discussion revolved around two different interpretations of the Remarks:

• It's normative recommendation for path objects to cache some kind of flag that indicates they are in a normalized form, which would be checked in weakly_canonical to avoid normalizing again. This is the interpretation assumed by the NB comment, which correctly notes that such caching would be unreliable.
• It's an optimization hint to implementors that they should not normalize the result if each component has been canonicalized one-by-one. That is, when canonicalizing "/a/b/c" by incrementally building up canonicalized components, if the entire path exists then the result will already have been normalized and should not be normalized again explicitly.

For the first interpretation, the recommendation is a bad recommendation and should be removed as suggested by the comment. For the second interpretation, we don't need to give hints to implementors about not doing unnecessary work; they already know they shouldn't do that. Either way, it should go.

This addresses NB comment US-60-125 ([fs.op.weakly.canonical] Avoiding normalization)

NB comment: "Implementations cannot avoid normalization because arbitrary file system changes may have occurred since any previous call. Proposed change: Remove the paragraph."