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.

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

regex 1.0 #230

Closed
wants to merge 18 commits into from
Closed

regex 1.0 #230

wants to merge 18 commits into from

Conversation

BurntSushi
Copy link
Member

This is a series of commits corresponding to my proposed changes for regex 1.0. It's still a work in progress and shouldn't be merged until an RFC is accepted.

@BurntSushi BurntSushi added this to the 1.0 milestone May 7, 2016
@alexcrichton
Copy link
Member

🚀 Nice!

Would it make sense to draw up a short summary of the breaking changes from the current 0.1 release train?

@BurntSushi
Copy link
Member Author

@alexcrichton Oh yes, that will be in the RFC. I can add the relevant pieces to the commit messages too. It's a WIP. :-)

@BurntSushi BurntSushi force-pushed the rfc branch 2 times, most recently from c4f0655 to 135b1e9 Compare May 18, 2016 23:23
@Amanieu
Copy link
Member

Amanieu commented May 30, 2016

You should also consider raising the minimum Rust version. For example, regex currently requires Rust 1.4 on Windows.

@BurntSushi
Copy link
Member Author

@RustPowers Please comment on the RFC instead: rust-lang/rfcs#1620

(The Pattern trait is unstable.)

This uses the new Replacer trait essentially as defined in the `bytes`
sub-module and described in #151.

Fixes #151
It is useless because it will always return false (since every regex has
at least one capture group corresponding to the full match).

Fixes #179
It is misleading to suggest that Regex implements equality, since
equality is a well defined operation on regular expressions and this
particular implementation doesn't correspond to that definition at all.

Moreover, I suspect the actual use cases for such an impl are rather
niche. A simple newtype+deref should resolve any such use cases.

Fixes #178
This corrects a gaffe of mine. In particular, both types contain
references to a `Captures` *and* the text that was searched, but
only names one lifetime. In practice, this means that the shortest
lifetime is used, which can be problematic for when one is trying to
extract submatch text.

This also fixes the lifetime annotation on `iter_pos`, which should be
tied to the Captures and not the text.

It was always possible to work around this by using indices.

Fixes #168
This is replaced by using RegexBuilder.

Fixes #166
It encourages compiling a regex for every use, which can be convenient
in some circumstances but deadly for performance.

Fixes #165
Similarly, rename RegexSplitsN to SplitsN.

This follows the convention of all other iterator types. In general,
we shouldn't namespace our type names.
Mostly, this adds an `Iter` suffix to all of the names.
These are tested automatically.
If `replace` doesn't find any matches, then it can return the original
string unchanged.
This remove the InvalidSet variant, which is no longer used, and no
longer exposes the `regex_syntax::Error` type, instead exposing it as
a string.
@BurntSushi BurntSushi force-pushed the rfc branch 2 times, most recently from a82a96b to aba9c28 Compare August 5, 2016 04:11
This also removes Captures.{at,pos} and replaces it with Captures.get,
which now returns a Match. Similarly, Captures.name returns a Match as
well.
All use cases can be replaced with Regex::capture_names.
Weird that this cfg_attrs didn't get pulled in during the rebase...
@BurntSushi BurntSushi force-pushed the rfc branch 3 times, most recently from 4fc851e to 44bcbce Compare August 21, 2016 21:40
Specifically, use mutable references instead of passing ownership.
@liigo
Copy link

liigo commented Oct 19, 2016

Ping. rust-lang/rfcs#1620 was approved last month. Any plan on regex 1.0?

@BurntSushi
Copy link
Member Author

Closing in favor of #310.

@BurntSushi BurntSushi closed this Dec 30, 2016
@BurntSushi BurntSushi deleted the rfc branch December 30, 2016 06:10
@upsuper
Copy link

upsuper commented Mar 19, 2017

Is regex going to be part of std, or would it remain an independent crate that developers would still need to specify in Cargo.toml and download and build locally?

@BurntSushi
Copy link
Member Author

@upsuper There are no plans to move regex into std.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants