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

strings: document that order of pairs matters in NewReplacer #32699

Closed
pam4 opened this issue Jun 19, 2019 · 5 comments
Closed

strings: document that order of pairs matters in NewReplacer #32699

pam4 opened this issue Jun 19, 2019 · 5 comments
Labels
Documentation FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@pam4
Copy link

pam4 commented Jun 19, 2019

The current documentation doesn't specify the result of the following code (could be either "declare" or "decodel") because they both match at the same starting position:

strings.NewReplacer("decl", "declare", "dec", "decode").Replace("decl")

The actual result is "declare", i.e. the first pair takes precedence (not the longest old string).
I just run into a use case that would require this precedence to be guaranteed, but I can't rely on it because it's not documented.

Looking at the code I presume the precedence is intentional: the generic algorithm uses a lookup trie for prioritized key/value pairs, and keys are added with decreasing priority, see here (len(oldnew)-i is the priority).

Unless there is actually a reason for it to be left undefined, I propose something like:

Leftmost matches take precedence, and among those, the leftmost pair in NewReplacer's arguments takes precedence.

Ok, hopefully someone will come up with better words...

@dmitshur dmitshur added this to the Go1.14 milestone Jun 20, 2019
@dmitshur dmitshur added the NeedsFix The path to resolution is known, but the work has not been done. label Jun 20, 2019
@dmitshur dmitshur modified the milestones: Go1.14, Go1.13 Jun 20, 2019
@rentziass
Copy link
Contributor

Leftmost matches take precedence, and among those, the leftmost pair in NewReplacer's arguments takes precedence.

I think this is clear. Maybe

Leftmost matches take precedence, and among those, the leftmost matching pair in NewReplacer's arguments takes precedence.

But maybe that's obvious 🤔

@pam4
Copy link
Author

pam4 commented Jul 5, 2019

Thanks for your insight.

I find a little confusing that the first "leftmost" is relative to the target string while the second is relative to the order of the arguments, so maybe we should get rid of the latter:

Leftmost matches take precedence, and among those, the matching pair appearing earlier in NewReplacer's arguments takes precedence.

But I'm not sure how integrate the "non overlapping" part. Here's another try:

The leftmost match in the target string is replaced first. If more than one match is possible at the same starting position, the matching pair appearing earlier in NewReplacer's arguments is used. Then the search is repeated on the remaining substring and so on, without overlapping matches.

@andybons andybons modified the milestones: Go1.13, Go1.14 Jul 8, 2019
@rentziass
Copy link
Contributor

@pam4 I like this one! How about this? Sounds maybe a little simpler to me

When multiple matches are found at the same starting position, the matching pair appearing earlier in NewReplacer's arguments is used.

But I feel like we could go on forever 😄 Maybe it's time to submit a CL? Do you want to do it or should I go ahead?

@pam4
Copy link
Author

pam4 commented Jul 9, 2019

@rentziass, your wording sounds fine to me. Please go ahead with the CL if you are willing. Thanks!

@gopherbot
Copy link

Change https://golang.org/cl/185099 mentions this issue: strings: document that order of pairs matters in NewReplacer

@golang golang locked and limited conversation to collaborators Jul 9, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation FrozenDueToAge help wanted NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants