delete RevString #22611
Assignees
Milestone
Comments
ararslan
added a commit
that referenced
this issue
Sep 7, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611.
Closed
ararslan
added a commit
that referenced
this issue
Sep 7, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611.
ararslan
added a commit
that referenced
this issue
Sep 8, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611.
ararslan
added a commit
that referenced
this issue
Sep 10, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611.
ararslan
added a commit
that referenced
this issue
Sep 10, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611.
ararslan
added a commit
that referenced
this issue
Sep 20, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611.
ararslan
added a commit
that referenced
this issue
Sep 20, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611. Calling `reverse` on an `AbstractString` with no more specific method has been deprecated in favor of explicitly converting to `String` before reversing.
ararslan
added a commit
that referenced
this issue
Sep 21, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611. Calling `reverse` on an `AbstractString` with no more specific method has been deprecated in favor of explicitly converting to `String` before reversing.
ararslan
added a commit
that referenced
this issue
Sep 21, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611. Calling `reverse` on an `AbstractString` with no more specific method has been deprecated in favor of explicitly converting to `String` before reversing.
ararslan
added a commit
that referenced
this issue
Sep 21, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611. Calling `reverse` on an `AbstractString` with no more specific method now unconditionally returns a `String`.
ararslan
added a commit
that referenced
this issue
Oct 7, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611. Calling `reverse` on an `AbstractString` with no more specific method now unconditionally returns a `String`.
ararslan
added a commit
that referenced
this issue
Nov 22, 2017
The `RevString` type for lazily reversed strings has been moved to the LegacyStrings package. Fixes #22611. Calling `reverse` on an `AbstractString` with no more specific method now unconditionally returns a `String`.
StefanKarpinski
added a commit
that referenced
this issue
Nov 22, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
StefanKarpinski
added a commit
that referenced
this issue
Nov 22, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
StefanKarpinski
added a commit
that referenced
this issue
Nov 27, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
StefanKarpinski
added a commit
that referenced
this issue
Nov 28, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
StefanKarpinski
added a commit
that referenced
this issue
Nov 29, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
StefanKarpinski
added a commit
that referenced
this issue
Dec 4, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
StefanKarpinski
added a commit
that referenced
this issue
Dec 4, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close #22611 Close #24613 See also: #10593 #23612 #24103
evetion
pushed a commit
to evetion/julia
that referenced
this issue
Dec 12, 2017
These seem unrelated, but they're actually linked: * If you reverse generic strings by wrapping them in `RevString` then then this generic `reverseind` is incorrect. * In order to have a correct generic `reverseind` one needs to assume that `reverse(s)` returns a string of the same type and encoding as `s` with code points in reverse order; one also needs to assume that the code units encoding each character remain the same when reversed. This is a valid assumption for UTF-8, UTF-16 and (trivially) UTF-32. Reverse string search functions are pretty messed up by this and I've fixed them well enough to work but they may be quite inefficient for long strings now. I'm not going to spend too much time on this since there's other work going on to generalize and unify searching APIs. Close JuliaLang#22611 Close JuliaLang#24613 See also: JuliaLang#10593 JuliaLang#23612 JuliaLang#24103
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
RevStringis (aside fromSubString) the only funky string type remaining in the standard library. It's used internally forrsearch, REPL completions, and some shell functionality. If we can figure out how else to implement those, then we can delete this type and move it to LegacyStrings. Part of #16107.The text was updated successfully, but these errors were encountered: