Feature #22238: String#tr to take a Hash for multi-character replacements

• Status: Open
• Assignee: -
• Target version: -

[byroot (Jean Boussier)]

This is @matz's counter proposal to [Feature #22229] from the last dev-meeting

matz: I will counter-propose String#tr-with-hash style.

'Hello </script>'.tr(">" => '\u003e', "<" => '\u003c', "&" => '\u0026') # matz: OK

'Hello </script>'.tr("abc" => 'ABC') # should raise an exception
'Hello </script>'.tr("abc" => 'ABC', "ab" => "XY") # should raise an exception

"fée".tr("é" => "€") # it should work

"Hello".tr("l" => "ABC", "o" => "XYZ") #=> "HeABCABCXYZ"

"Hello".gsub(/./m) { hash[$&] || $& } # gsub equivalent

Notes:

• Hash keys MUST be single characters (but can be multi-byte).
• Values can be multiple characters.

[byroot (Jean Boussier)]

• Related to Feature #22229: Allow GCI.escapeHTML to take a custom escape table added

[nobu (Nobuyoshi Nakada)]

byroot (Jean Boussier) wrote:

• Hash keys MUST be single characters (but can be multi-byte).

I think it would be worth to clarify: "character" means "codepoint" here not including combined characters, as well as String#tr does now.

• Status changed from Open to Closed

Applied in changeset git|9144c914a1a51176d461c06e11bc78723c2c24cb.

---

Fix GC compaction re-embedding for arrays and strings

Don't re-embed after compaction for these types if they are pinned because if these objects
aren't embedded we want to keep their xmalloc's backing storage intact so that RARRAY_PTR
and RSTRING_PTR don't point to freed memory across a compaction event. If the object is pinned
we want to be able to trust that these pointers can't go stale across an allocation.

Fixes [Bug #22238]

[luke-gru (Luke Gruber)]

• Status changed from Closed to Open

The commit in the previous message has the wrong Issue ID, it is unrelated.