P1030 R7 std::filesystem::path_view

[wg21bot]

P1030R2 std::filesystem::path_view (Niall Douglas)

[tituswinters]

LEWG-I doesn't seem necessary here, LEWG is taking it.

[tahonermann]

SG16 2019-07 review in Cologne

Polls taken:

Attendance: 13

P1030R2 - std::byte oriented interfaces should be provided with the understanding that the interface will require implementation defined semantics.

SF	F	N	A	SA
5	5	1	0	1

That has consensus.

SA: This is a foot gun. The semantics are implementation defined and non-portable.

P1030R2 - char and wchar_t oriented interfaces should be provided that behave according to the std::filesystem::path specification in terms of encoding.

SF	F	N	A	SA
3	2	0	4	2

No consensus.

P1030R2 - char32_t oriented interfaces should be provided that behave according to the std::filesystem::path specification in terms of encoding.

SF	F	N	A	SA
2	2	4	2	2

No consensus.

The author was present.

Dropping the SG16 label.

[tituswinters]

Discussed in Cologne - http://wiki.edg.com/bin/view/Wg21cologne2019/P1030

Encourage more work (use the ‘is_null_terminated’ tag idea). Include benchmarks. Unanimous consent

Needs revision.

[wg21bot]

P1030R3 std::filesystem::path_view (Niall Douglas)

[tahonermann]

SG16 reviewed P1030R3 in Belfast.

No polls were taken. SG16 feedback to the author included suggestions to delete operator== since no useful semantics can be efficiently implemented.

Removing the SG16 label.

SG16 minutes are available at:

• http://wiki.edg.com/bin/view/Wg21belfast/SG16P1030R3

[FabioFracassi]

__POLL: Do we want path_view.compare<>() to do what path.compare() does?__

Unanimous

POLL: We like the design of the paper, ask the author to provide wording and come back.

Strongly For	Weakly For	Neutral	Weakly Against	Strongly Against
5	3	3	0	0

[ned14]

FYI now the kids have finally gone back to school this week, I can restart writing WG21 papers. As this is the only of my papers where wording was requested, it'll be first up. It will be my first time writing normative wording. Is there anywhere I can get a peer review of a draft before I submit R4 in order to save committee time from newbie mistakes?

[tahonermann]

@ned14, this isn't the right place to discuss this (these issues are for tracking issue status and poll results; mostly for WG/SG chairs and assistants). I suggest you ask the LWG chair to recommend a wordsmith for you to work with.

[ned14]

@tahonermann Thanks for the advice. The draft will be passing you and Billy O'Neal before anyone else in any case. Once you and Billy are happy with it, I'll ask LWG for wordsmith volunteers. First draft should be a few weeks out, I get very little time each morning to write this stuff, and much of [filesystem] needs to be touched.

[wg21bot]

P1030R4 std::filesystem::path_view (Niall Douglas)

[brycelelbach]

2021-02-23 Library Evolution Telecon

Chair: Bryce Adelstein Lelbach

Champion: Niall Douglas

Minute Taker: Mark Hoemmen

Start: 2021-02-23 11:05 Pacific

Does this proposal have:

• Examples?
  • Yes.
• Implementation experience?
  • Yes.
• Usage experience?
  • Unclear.
• Deployment experience?
  • Unclear.
• Performance considerations?
  • Yes.
• Discussion of prior art?
  • Unclear
• Changes Library Evolution previously requested?
  • Yes.
• Wording?
  • Yes.
• Feature test macro?
  • No.

Last time Library Evolution reviewed this, we said "we like the design of the paper, ask the author to provide wording and come back."

This has been reviewed and blessed by the Text and Unicode study group.

Why is there a separate mechanism for passing in a memory_resource?

Can path_view::c_str be removed entirely as unnecessary?

Is there an alternative way to get a null-terminated byte string?

If we keep path_view::c_str, we probably need to give it a different name.

Why isn't path_view::c_str a member function that returns a null-terminated string?

POLL: path_view should support a mechanism for getting a null-terminated multi-byte string.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
9	9	0	0	0

Attendance: 25

# of Authors: 1

Author Position: SF

Outcome: Unanimous consensus in favor.

POLL: path_view should have a member function that returns an object that has either a data member or a member function that gives you a string that can be passed to a system call.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	17	1	1	0

Attendance: 25

# of Authors: 1

Author Position: WF

Outcome: Consensus in favor.

POLL: The class template formerly known as path_view::c_str should have member functions instead of data members for access.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
7	11	2	0	0

Attendance: 23

# of Authors: 1

Author Position: SF

Outcome: Consensus in favor.

Author is directed to come up with a short list of naming suggestions with strong rationale for path_view::c_str.

End: 11:55

Summary

In this review of filesystem::path_view, we focused on path_view::c_str, the facility for getting a string that can be passed to system calls from a path_view.

We considered the possibility of removing the facility entirely, which had been discussed to some extent on the mailing list. We had consensus that it is important to have a facility for getting a null-terminated string and a string that can be passed to system calls. We also had consensus that the basic shape of c_str is an acceptable for providing that functionality. We do want path_view to have a function that returns a c_str, and we want c_str to have member functions, not data members, for access.

It was also pretty clear from our discussion that c_str was not the right name for the facility. It clashes with string::c_str, which is a member function and has different syntax and semantics. We asked the author to return with a short list of naming suggestions with strong rationale in the next revision.

Now that the question of c_str has been resolved, the paper will proceed to mailing list review to iterate on the draft wording.

Outcome

Bring a revision of P1030R4 (std::filesystem::path_view), with the guidance below, to Library Evolution for further design review.

• Add a member function to path_view that returns a path_view::c_str.
• Remove the public data members and add member functions for accessing the contents of a path_view::c_str.
• Produce a short list of naming suggestions (with strong rationales) for the facility formerly known as path_view::c_str.

[wg21bot]

P1030R5 std::filesystem::path_view (Niall Douglas)

[ned14]

Can my memory be confirmed that we didn't see this at Issaquah, and we intend to see it in Varna?

[inbal2l]

2023-06-15 Library Evolution Varna

P1030R5: std::filesystem::path_view

2023-06-15 Library Evolution Minutes

Chair: Bryce Adelstein Lelbach, Inbal Levi

Champion: Niall Douglas

Minute Taker: Mark Zeren

Summary

POLL: We want a render overload that returns a null-terminated path.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
13	7	0	0	0

Attendance: 22 (P) + 2 (R)

# of Authors: 1

Author Position: N/A

Outcome: Consensus in favor (weak voting rate)

POLL: We want a render overload that doesn't guarantee it returns a null-terminated path.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
5	3	4	2	2

Attendance: 22 (P) + 2 (R)

# of Authors: 1

Author Position: SF

Outcome: Weak consensus in favor

SA: I don't think the optimizations are very compelling.

WA: This exists to interface with low-level C APIs that expect null termination.

POLL: Remove the form of render that doesn't guarantee that it returns a null-terminated path.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	5	4	2	4

Attendance: 22 (P) + 2 (R)

# of Authors: 1

Author Position: SA

Outcome: No consensus for change.

POLL: The null-terminated render function should be called render.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	4	2	9	2

Attendance: 23 (P) + 3 (R)

# of Authors: 1

Author Position: SA

Outcome: No consensus.

POLL: The null-terminated render function should be called render_null_terminated.

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
3	13	1	1	1

Attendance: 23 (P) + 4 (R)

# of Authors: 1

Author Position: WF

Outcome: Consensus in favor.

SA: I don't like either of the names because I don't like "render". I don't think they're meaningful.

WA: It's too long for what should be the default option.

__POLL: The unterminated render function should be called render_unterminated.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
2	10	6	1	1

Attendance: 23 (P) + 4 (R)

# of Authors: 1

Author Position: WF

Outcome: Weak consensus in favor.

SA: The names are too similar-ish. I liked the old names, except for "zero".

__POLL: Remove the render<enum zero_termination> template function.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
4	6	7	2	0

Attendance: 23 (P) + 4 (R)

# of Authors: 1

Author Position: WA

Outcome: Consensus in favor, remove the render<enum zero_termination> template function.

Locals: We should replace locales with encodings, or for now just remove locales.

__POLL: Remove locale support from path_view.__

Strongly Favor	Weakly Favor	Neutral	Weakly Against	Strongly Against
11	8	2	1	0

Attendance: 28 (P) + 4 (R)

# of Authors: 1

Author Position: SF

Outcome: Strong consensus in favor.

WA: I would prefer to remove them when we have the replacement.

Next Steps

Action Items:

• rendered_path should only depend on backing storage, never its parent path_view, regardless of whether it owns its own storage or not.
• NonLegacyPath should be called NonLegacyCpp17Path.
• PathView and NonLegacyPath should consistently be named type requirements, not concepts.
• Remove the render<enum zero_termination> template function.
• Remove enum zero_termination or make it exposition only.
• Rename render_zero_terminated to render_null_termianted.
• Rename render_not_zero_terminated to render_unterminated.
• Change the new overloads for open to be multiple overloads, instead of pseudo-concepts.
• Fix calls to render_* to be member function calls.
• Remove the overloads for const byte* and span<const byte>.
• Get field experience with implementing the new overloads of existing standard library functions in a standard library and successfully running the standard libraires test suite.
• Go back to the Text and Unicode study group for additional review.
• Make sure that path_view::formatting is implementable without an ABI break.
• Include all of existing path in the diff.
• Delete all the notes to Library Evolution in the wording.

Open Questions:

• Lifetimes.

[ned14]

In Varna, LEWG requested that SG16 Unicode review the LEWG decision to remove the std::locale overloads in R6 of this paper. Yesterday SG16 Unicode met and polled to not restore those overloads i.e. they agreed with the LEWG decision.

[wg21bot]

P1030R6 std::filesystem::path_view (Niall Douglas)

[tahonermann]

SG16 reviewed P1030R6 during its 2023-07-12 meeting. The following polls were taken in order to confirm recent LEWG direction.

• Poll 1: Modify P1030R6 "std::filesystem::path_view" to restore function overloads with locale parameters.

  • Attendees: 12 (4 abstentions)	SF	F	N	A	SA
    0	0	2	4	2

  • Consensus against.

The consensus against position is in agreement with LEWG direction (LEWG had established consensus to remove the overloads that the poll was phrased to restore).

[inbal2l]

SG9 should look at this, to make sure it's consistent with "views" as they see it in terms of lifetime and ownership. Please add an LEWG tag once you're done.

[dhollman]

I'm planning to schedule this for Kona. I will try to find a slot that is timezone compatible with the author's timezone (probably first thing in the morning?)

[ned14]

In the SG9 Ranges meeting on path_view earlier today, it was asked why the path view render() functions are not const-qualified. I said I would go see why not as I didn't know. I can confirm it was an oversight in the reference implementation which propagated into the paper. It has been fixed in the reference implementation and will be fixed in R7 of this paper. Thanks to whomever spotted it.

[ned14]

SG9 Meeting Kona 2023-11-06

__POLL: SG9 generally recommends against something named _view allocating in a non-special member function (in other words, SG9 notes that this is a downside of the current design).__

SF	F	N	A	SA
1	0	2	5	0

Consensus: No consensus for change.

Attendance: 11 (6 in person, 5 online)

Author position: A (collaborators N & A)

POLL: SG9 recommends that the authors pursue an alternative design that doesn’t involve a type that is both owning and non-owning.

SF	F	N	A	SA
0	1	1	4	2

Result: No consensus for change.

Attendance: 11 (6 in person, 5 online)

Author position: SA (collaborators A & SA)

POLL: SG9 would prefer to have a separate, more general-use type for “maybe-owning” strings (which this paper would use if standardized in time)?

SF	F	N	A	SA
2	2	4	1	0

Result: Consensus in favor

Attendance: 11 (6 in person, 5 online)

Author position: F (collaborators F & N)

POLL: SG9 believes that having a move constructor exposes this type to misuse.

SF	F	N	A	SA
0	3	3	2	1

Result: Not consensus.

Attendance: 11 (6 in person, 5 online)

Author position: A (collaborators A & SA)

__POLL: SG9 recommends that SG23 see this (because of the owning/non-owning nature of rendered_path)__

SF	F	N	A	SA
2	0	3	4	0

Result: Consensus against.

Attendance: 11 (6 in person, 5 online)

Author position: A (collaborators A & N)

@inbal2l I would infer from the above that SG9 does think path view is consistent with "views" as they see it in terms of lifetime and ownership, though it's not a slam dunk obvious inference.

[inbal2l]

P1030R6 std::filesystem::path_view (Niall Douglas)

[mhoemmen]

@ned14 wrote:

In the SG9 Ranges meeting on path_view earlier today, it was asked why the path view render() functions are not const-qualified. I said I would go see why not as I didn't know. I can confirm it was an oversight in the reference implementation which propagated into the paper. It has been fixed in the reference implementation and will be fixed in R7 of this paper.

FYI, the render functions were removed entirely in R6, so this comment is moot.

EDIT: What about render_null_terminated and render_unterminated? They are not marked const.

EDIT: They should be marked const (see minutes).

[ned14]

My notes on changes requested at the St. Louis meeting:

• render null terminated and render unterminated should be const.
• conditions on c_str() are too strict.
• @vitaut would prefer something "better" for ABI for the visitor interface (I would love to hear suggestions, returning a variant still has the ABI problem if the types returned change).

[FabioFracassi]

2024-06-25 Library Evolution St. Louis Meeting (Second Morning Session)

P1030R6: std::filesystem::path_view

2024-06-25 Library Evolution St. Louis Meeting Minutes

Champion: Naill Douglas Chair: Fabio Fracassi / Mark Hoemmen Minute Taker: Eddie Nolan

Summary

The next revision of the paper should contain:

• Discussion/Clarification of ABI and code evolution concerns of adding new encodings is required.
• A Formatter should be provided
• Add discussion on which header this goes into
• Deployment experience for overload sets where path-view-like is added would help to remove doubts
• Make sure that errors are provided via error codes in the error code overloads of file-system
• Page 18 contains some drive-by fixes to filesystem::path, which would be interesting regardless of the rest of the proposal

Next Steps

No polls were taken, the discussion on the paper continued during the next session.

[inbal2l]

2024-06-25 Library Evolution St. Louis Meeting (First Afternoon Session)

P1030R6: std::filesystem::path_view

2024-06-25 Library Evolution St. Louis Meeting Minutes

Champion: Naill Douglas Chair: Fabio Fracassi / Mark Hoemmen Minute Taker: Steve Downey

Summary

In addition to the fixes required during the previous session, we took the following polls:

POLL: Prefer to choose the path-view-like overload over the existing filesystem::path overload in the free functions (fs.filesystem.syn, e.g. copy_file)

SF	F	N	A	SA
1	4	3	3	0

Attendance: 14 + 5 # of Authors: 1 Author's Position: WA Outcome: not consensus

POLL: We approve of the design of P1030R6 (modulo new information and the action items)

SF	F	N	A	SA
3	7	1	1	0

Attendance: 14 + 7 # of Authors: 1 Author's Position: SF Outcome: consensus in favour

Next Steps

The author will apply the fixes required during the previous session, as well as the results of the polls and publish an R7. The general design was approved, the details of the design and a wording review is still required by LEWG.

[wg21bot]

P1030R7 std::filesystem::path_view (Niall Douglas)