Bug #18241
closed
Question on String Concatentation Documentation
Added by hernanat (Anthony Hernandez) about 3 years ago.
Updated almost 3 years ago.
Description
Hello,
I noticed that the documentation for <<
and concat
both state that the result of each operation is a new string.
However, while doing some experimenting myself I noticed that this doesn't seem to be the case. The result has the same object id and memory address as the initial string.
I also noticed that the underlying C code fore both of these does seem to return the original string pointer at the end.
Is this a documentation issue, or is there something else going on that I'm missing? If the former, I'm happy to put up a PR to fix. If it's the latter, I'd appreciate any explanation.
Thanks
Anthony
edit: to be clear, I'm making a distinction between "new string" in the contents-sense, and "new string" in the memory location sense.
For example, the <<
operation on Array
inserts an array entry and returns self
, which is why I was initially confused when I saw that the result of String#<<
was a new string.
- Tracker changed from Misc to Bug
- Backport set to 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
This is a documentation bug. Both String#<< and String#concat mutate and return the receiver. I'll fix this shortly.
- Status changed from Open to Closed
- Has duplicate Bug #18261: String#prepend inconsistent documentation added
- Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN to 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: REQUIRED
- Backport changed from 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: REQUIRED to 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: DONE
ruby_3_0 62a33dfa168504f8ee77d493979e66616ebe1da8 merged revision(s) c6706f15af123bdbb3b39a21903d85c78462d047.
Also available in: Atom
PDF
Like0
Like0Like0Like0Like0Like0Like0