Comparing changes

Now we have: - chomp: removes trailing '\n' or \'r\n' - chomp(suffix): removes suffix (if suffix is '\n' it acts as `chomp()`) - rchop: removes last char - rchop(suffix): removes suffix - lchop: removes first char - lchop(prefix): removes prefix We remove `'lchomp` We also have: - strip: removes leading and trailing whitespace - strip(char): removes all leading and trailing occurrences of char - strip(string): removes all leading and trailing occurences of any char of string - lstrip, rstrip: similar to the above three, but only in one side of the string With this we have pretty much covered all ways to remove things from the front/end of a String in a consistent way. There's `chomp` that has no right/left version, but that came from Ruby and is very specific to removing a trailing newline. The chomp(arg) variant is kept because one can do `io.gets(delimiter, chomp: true)` and that would be equivalent to doying `io.gets(delimiter).chomp(delimiter)`.

…o_unsafe_slice` for an unsafe version. The `to_slice` method was unsafe as it could lead to segfaults if one wrote to the returned bytes. For example: ``` string = "hello" string.to_slice[0] = 0_u8 ``` However, there's nothing obviously unsafe by looking at the previous snippet. This isn't good, because as a general rule unsafe methods should have "unsafe" in their name. To fix this, we make `to_slice` return a copy of the bytes, which can be safely mutated. We also add `to_unsafe_slice` which returns an unsafe view of the bytes, which might lead to unsafe code if one mutates the returned bytes. Because some methods invoked `to_slice` on String only for read-only behaviour without expecting a copy, this might now introduce allocations that didn't exist before. To fix that we introduce `Slice.unsafe_readonly(data)` that will invoke `to_unsafe_slice` on String and `to_slice` on everything else. This is used in, for example, Base64, Adler32, MD5, CRC32, etc. We also make `IO::Memory#to_slice` return a copy, for the same reasons, providing `IO::Memory#to_unsafe_slice` too.

…means a byte value, not a codepoint. Added hex escape inside strings (byte value).

…quence. - String methods now never raise InvalidByteSequenceError - Added String#valid_encoding? to determine if it's properly encoded - Added String#scrub to replace invalid byte sequences - String#inspect and String#dump don't raise, and use \xHH for invalid byte sequences Fixes #2159 Fixes #2130

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Comparing changes

Open a pull request

Commits on Feb 18, 2017

This comparison is taking too long to generate.