Uh oh!
There was an error while loading. Please reload this page.
Add escape_ascii method to u8 and [u8] - #73111
Conversation
rust-highfive
commented
Jun 8, 2020
(rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
commented
Jun 8, 2020
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
Mark-Simulacrum
commented
Jun 8, 2020
I feel like if these don't have ASCII in the name somehow they are quite confusing, and I'm not entirely sure if this is necessary over asking to convert to str and escaping that (perhaps via bstr crate). |
clarfonthey
commented
Jun 8, 2020
That's very fair -- I didn't know about the That said, I do think that the remaining method in the So, basically, to me, there are really two options: 1, deprecating in favour of the bstr crate, and 2, some form of this PR.
|
JohnCSimon
commented
Jun 16, 2020
Ping from triage: |
clarfonthey
commented
Jun 18, 2020
Sorry, I intentionally held off on fixing the code due to @Mark-Simulacrum's concerns about naming. Was going to wait to see if there's a consensus on that before fixing, as I can do both changes at once. |
Mark-Simulacrum
commented
Jun 18, 2020
Inherent methods seem reasonable for the ASCII-specific stuff, vs. having free-standing functions in the ASCII module. I'm going to r? @BurntSushi as this sort of deals with the whole "Unicode" thing and bstr tangentially |
Muirrum
commented
Jul 24, 2020
@BurntSushi This is a triage bump. |
bors
commented
Jul 28, 2020
☔ The latest upstream changes (presumably #73265) made this pull request unmergeable. Please resolve the merge conflicts. |
JohnCSimon
commented
Aug 11, 2020
@clarfon |
clarfonthey
commented
Aug 11, 2020
Will try to get to that soon. |
d5dc387 to
4745f42Compareclarfonthey
commented
Aug 16, 2020
Rebased; the current errors appear to be unrelated to this change. |
There was a problem hiding this comment.
hand-wavy concern: I believe all the ascii_xxx methods on u8 ideally should have had self rather than &self argument, to be consistent with all other methods. The reason for &self I believe is historical, dating back to AsciiExt trait.
Should we use &self here to be consistent with other ascii method, or should we use self, to be consistent with non-ascii methods, and with the general pattern that small things are passed by self?
There was a problem hiding this comment.
Agree with you, am fine with either convention.
There was a problem hiding this comment.
Let's use self here instead of &self. In this case there's not much value in keeping consistency with this historical 'mistake'. (Since some_byte.escape_ascii() will work either way.)
bors
commented
Sep 4, 2020
☔ The latest upstream changes (presumably #75207) made this pull request unmergeable. Please resolve the merge conflicts. |
m-ou-se
commented
Dec 30, 2020
Thanks for working on this. I have two small comments left, see above. Other than that, this looks ready to be merged. |
m-ou-se
commented
Dec 30, 2020
Oh, one more thing: This now uses both |
clarfonthey
commented
Dec 30, 2020
Oh, yes, I did. Must have been a find-replace error. Will try and remember to get to this in a few hours when I'm done with work. |
camelid
commented
Jan 6, 2021
(I changed the PR title to reflect that it adds |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
clarfonthey
commented
Jan 17, 2021
Finally got to this and rebased with the feature flag fixed and suggestions applied, although I reworded the [u8] docs to be more consistent with the u8 docs. |
rust-log-analyzer
commented
Jan 17, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Camelid <camelidcamel@gmail.com>
rust-log-analyzer
commented
Jan 17, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Camelid <camelidcamel@gmail.com>
rust-log-analyzer
commented
Jan 18, 2021
The job Click to see the possible cause of the failure (guessed by this bot) |
camelid
commented
Jan 18, 2021
Hmm, I'm not sure why the intra-doc links aren't resolving... |
clarfonthey
commented
Jan 18, 2021
Pretty sure it's because |
camelid
commented
Jan 18, 2021
|
camelid
commented
Feb 12, 2021
What is the status of this? |
Dylan-DPC-zz
commented
Feb 13, 2021
@clarfonthey |
escape_ascii take 2 The previous PR, rust-lang#73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one. I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this. r? `@m-ou-se`
escape_ascii take 2 The previous PR, rust-lang#73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one. I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this. r? ``@m-ou-se``
escape_ascii take 2 The previous PR, rust-lang#73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one. I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this. r? `@m-ou-se`
escape_ascii take 2 The previous PR, rust-lang#73111 was closed for inactivity; since I've had trouble in the past reopening closed PRs, I'm just making a new one. I'm still running the tests locally but figured I'd open the PR in the meantime. Will fix whatever errors show up so we don't have to wait again for this. r? ``@m-ou-se``
Essentially, this closes an inconsistency gap between
char/strandu8/[u8].Right now the
EscapeDefaulttype used in[u8]::escape_defaultis exported incore::slice, and it may make sense to movecore::ascii::EscapeDefaultintocore::u8as well. But for now, this leaves thecore::asciimodule alone and just calls its methods.