P1030 R8 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]

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)

[cor3ntin]

Related paper #2056

[inbal2l]

2024-11-18 Library Evolution Wroclaw Meeting

P1030R7 std::filesystem::path_view

2024-11-18 Library Evolution Wroclaw Meeting Minutes

Champion: Victor Zverovich
Chair: Inbal Levi / Fabio Fracassi
Minutes: Robert Leahy

Summary

Related to P2645.

ACTIONS: Add discussion as part of P1030 (after getting input from SG16):

1. Re-consider full transcoding - reduce support in win platform (char *)
2. Consider equivalent
3. Do we need path_view for C++26
4. Do we need the full overload set (the one that matches path)

No polls were taken at this time.

Next Steps

As a follow-up, Naill has discussed with Victor about removing the win-related transcoding to avoid complications of the type.
We will discuss the paper again with alternatives suggested for the topics above.

[wg21bot]

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