Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tracking issue for RFC 2295, "Extend Pattern API to OsStr" #49802

Open
3 tasks
Centril opened this issue Apr 9, 2018 · 12 comments
Open
3 tasks

Tracking issue for RFC 2295, "Extend Pattern API to OsStr" #49802

Centril opened this issue Apr 9, 2018 · 12 comments
Labels
A-FFI Area: Foreign function interface (FFI) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@Centril
Copy link
Contributor

Centril commented Apr 9, 2018 •
edited by rustbot
Loading

This is a tracking issue for the RFC "Extend Pattern API to OsStr" (rust-lang/rfcs#2295).

Steps:

Unresolved questions:

None
@Centril Centril added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC labels Apr 9, 2018
@Centril Centril mentioned this issue Apr 9, 2018
Merged
@kennytm kennytm self-assigned this Apr 9, 2018
@clarfonthey clarfonthey mentioned this issue Apr 9, 2018
Closed
@SimonSapin SimonSapin mentioned this issue May 14, 2018
Open
@vhdirk vhdirk mentioned this issue May 27, 2018
Merged
@ismaelgv ismaelgv mentioned this issue Jul 12, 2018
Open
@kennytm
Copy link
Member

kennytm commented Jul 17, 2018

Status update: I've got the implementation of this ready, but I'd like to wait for a decision on rust-lang/rfcs#2500 first, as I believe this isn't an urgent feature.

Without the pattern API part, this RFC will only provide the slicing operation (os_str[a..b]), which (1) is insta-stable as requires impl Index for OsStr, (2) the only indices that guaranteed to be valid are 0 and os_str.len(), and (3) slows down PartialEq/PartialOrd without much to return.

@1011X
Copy link
Contributor

1011X commented Mar 29, 2019

Now that rust-lang/rfcs#2500 has merged, can this RFC be implemented?

@SimonSapin SimonSapin mentioned this issue Jul 23, 2019
Closed
@casey casey mentioned this issue Sep 4, 2019
Open
@DutchGhost
Copy link
Contributor

@rustbot claim

@rustbot rustbot assigned rustbot and unassigned kennytm Apr 7, 2020
@Dylan-DPC-zz
Copy link

@rustbot unassign

@Dylan-DPC-zz
Copy link

@rustbot assign @Kixiron

@KodrAus KodrAus added A-FFI Area: Foreign function interface (FFI) Libs-Tracked Libs issues that are tracked on the team's project board. labels Jul 29, 2020
@jhwgh1968
Copy link

jhwgh1968 commented Jul 23, 2021 •
edited
Loading

Hey @rust-lang/libs-api team, since it was decided to revert the Needle/Pattern API stabilization, what is the status of this?

I hope it won't be reverted, too. It would still really help me with cross-platform compatibility.

@jhwgh1968 jhwgh1968 mentioned this issue Jul 23, 2021
Closed
@joshtriplett
Copy link
Member

@jhwgh1968 We're not planning on reverting impls of this trait; we're keeping the trait. We're just planning to seal it and not support implementations outside the standard library.

@epage epage mentioned this issue Apr 21, 2022
Closed
@jmillikin jmillikin mentioned this issue Sep 28, 2022
Closed
@pitaj
Copy link
Contributor

pitaj commented Feb 14, 2023

@rustbot claim

@pitaj
Copy link
Contributor

pitaj commented Feb 15, 2023 •
edited
Loading

Is like to try my hand at implementing this. I've read the RFC and the OMG-WTF-8 spec, but I want to make sure I understand the reason for OMG-WTF-8.

My understanding is that Windows does not require that various strings are actually valid UTF-16. Any [u16] will do. This is the reason for the existence of WTF-8: WTF-8 allows encoding any [u16] as an extension of UTF-8. However, WTF-8 is not flexible enough to allow slicing into the individual units from the [u16], it does not allow spitting surrogate pairs. That is what OMG-WTF-8 adds, and it makes various pattern APIs more ergonomic.

@kennytm you mention having an implementation ready. Is that just the omgwtf8 package, or did you have a rust branch set up? If the latter, please share.

Thanks!

mina86 added a commit to mina86/rust that referenced this issue Feb 16, 2023
@mina86
core: convert Pattern<'a> into Pattern<H: Haystack> (RFC 2295)
4391e6a 
As per RFC 2295, add a Haystack trait describing something that can be
searched in and make core::str::Pattern (and related types) generic on
that trait.  This will allow Pattern to be used for types other than
str (most notably OsStr).

The change mostly follows the RFC though there are some differences in
Haystack trait.

Most notably, instead of separate StartCursor and EndCursors types,
there’s one Cursor type instead.  This eliminate the need for methods
converting between the two types of cursors.

Conversion from cursor to offset isn’t included either since as far as
I can tell it’s not needed.  A generic code operating on Haystack
doesn’t need a concept of offset.  It can operate on cursors instead.

Lastly, rather than range_to_self as suggested in RFC this commit
implements split_at_cursor_unchecked which simplifies default
implementation of strip_prefix_of and strip_suffix_of.

For now leave Pattern, Haystack et al in core::str::pattern.  Since
they are no longer str-specific, I’ll move them to core::pattern in
future commit.  This one leaves them in place to make the diff
smaller.

Issue: rust-lang#49802
mina86 added a commit to mina86/rust that referenced this issue Feb 16, 2023
@mina86
core: move Pattern et al to core::pattern module (RFC 2295)
13fbed4 
Pattern is no longer str-specific, so move it from core::str::pattern
module to a new core::pattern module.  This introduces no changes in
behaviour or implementation.  Just moves stuff around and adjusts
documentation.

Issue: rust-lang#49802
mina86 added a commit to mina86/rust that referenced this issue Feb 16, 2023
@mina86
core: add core::pattern::loop_next helper function
0ff2270 
Negative delta FTW.

Issue: rust-lang#49802
mina86 added a commit to mina86/rust that referenced this issue Feb 16, 2023
@mina86
core: implement Pattern<&[T]> for &[T]; get rid of SlicePattern
7af0733 
Implement Haystack<&[T]> and corresponding Pattern<&[T]> for &[T].
That is, provide implementation for searching for subslices in slices.
This replaces SlicePattern type.

To make use of this new implementations, provide a few new methods on
[T] type modelling them after types on str.  Specifically, introduce
{starts,ends}_with_pattern, find, rfind, [T]::{split,rsplit}_once and
trim{,_start,_end}_matches.

Note that due to existing starts_with and ends_with methods, the
_pattern suffix had to be used.  This is unfortunate but the type
of starts_with’s argument cannot be changed without affecting type
inference and thus breaking the API.

This change doesn’t implement functions returning iterators such as
split_pattern or matches which in str type are built on top of the
Pattern API.

Issue: rust-lang#49802
Issue: rust-lang#56345
@mina86
Copy link
Contributor

mina86 commented Feb 16, 2023

@pitaj, FYI I’ve actually started looking into this myself. You can see stuff I’ve done so far at master...mina86:rust:wtf

For now this is just Pattern API stuff and not even exactly conforming to this RFC (see my comment under the RFC PR) (plus some Haystack<&[T]> shenanigans I've been toying around with to get a feel of the Pattern API.

I’ve just started looking at OsStr. To answer your question, yes, pretty much.

@pitaj
Copy link
Contributor

pitaj commented Feb 17, 2023

@mina86 cool! Are you on zulip? Are you open to collaborating on the implementation?

It's my understanding that Haystack no longer exists. Am I mistaken or are you working from an older version?

@mina86
Copy link
Contributor

mina86 commented Feb 17, 2023

You may be right about Haystack now that I read the RFC again. I’ll ping you on Zulip then.

@mina86 mina86 mentioned this issue Mar 19, 2023
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-FFI Area: Foreign function interface (FFI) B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC Libs-Tracked Libs issues that are tracked on the team's project board. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests