Ruby » Ruby master

Hmm, guessing that '+' and '%' are being a bit weird...

Verified the some thing happens in: ruby 2.0.0p481

It does look like '<<' is working (or not working) though.

irb(main):007:0> MyString.new("foo").<<("foo").class
=> MyString

--
Incoherently,
Ricky Ng

Ricky

Methods that modify the receiver and return the receiver would have to return the exact same object, which means that the class is the same. That is not the issue here.

Ahh yea, me being derpy =(. What I wanted to actually do was sanity
check some other methods that would return a new_str:

irb(main):005:0> MyString.new("hello")[0].class
=> MyString
irb(main):006:0> MyString.new("hello").byteslice(1).class
=> MyString
irb(main):007:0> MyString.new("hello").capitalize.class
=> MyString
irb(main):008:0> MyString.new("hello").center(1).class
=> MyString
irb(main):009:0> MyString.new("hello").chomp.class
=> MyString
irb(main):010:0> MyString.new("hello").chop.class
=> MyString
irb(main):011:0> MyString.new("hello").delete("ll").class
=> MyString
irb(main):012:0> MyString.new("hello").downcase.class
=> MyString
irb(main):013:0> MyString.new("hello").dump.class
=> MyString
irb(main):014:0> MyString.new("hello").gsub("ll", "LL").class
=> MyString

--
Incoherently,
Ricky Ng

I've added a pull request for making String methods consistently return String instances when called on String subclasses: https://github.com/ruby/ruby/pull/3701

For the reasons @marcandre (Marc-Andre Lafortune) mentioned, I think this makes more sense. Instance specific state is not copied over, and you can end up with invalid objects. If we are going to make similar changes for Array in 3.0 (see #6087), I think it's worth considering the same change for String.

I am OK with experimenting. But I've heard Rails relies on the old behavior (SafeStringBuffer?). In that case, it might be hard to apply this.

Matz.

I've heard Rails relies on the old behavior (SafeStringBuffer?)

Just commented about the impact of this patch on Rails (ActiveSupport::SafeBuffer) https://github.com/ruby/ruby/pull/3701#issuecomment-730960288

Is there are logic why we should prefer to return String vs custom subclass instances? I can see argument for both way. Why is one way preferred over the other?

@ioquatix (Samuel Williams) See #6087. Returning subclass instances leads to all kind of issues, because there is no good way to build the subclass instance.

+1 to do it for String since we did for Array.

Maybe we should do it for Hash too?
It seems already the case for most Hash methods but not all (e.g. Hash#merge).

Eregon (Benoit Daloze) wrote in #note-12:

Maybe we should do it for Hash too?
It seems already the case for most Hash methods but not all (e.g. Hash#merge).

I looked at Hash#merge, but it doesn't have the same issue as the String and Array methods, since it is implemented as dup.merge!, and dup copies the state into the new object instead of losing it.

jeremyevans0 (Jeremy Evans) wrote in #note-13:

I looked at Hash#merge, but it doesn't have the same issue as the String and Array methods, since it is implemented as dup.merge!, and dup copies the state into the new object instead of losing it.

Indeed, I think too that case is fine.

I checked all Hash methods listed in the docs and returning a Hash and not just returning self: compact, filter, select, reject, invert, transform_keys, transform_values, and all of them return Hash, except for merge:

h = SubHash.new
h[:foo] = 42

# Seems fine, uses #dup
h.merge({}).class # => SubHash

(keep_if returns self, that confused me)

So Hash is fine already :)

In 2.7 we break large compatibilities, and this tickets breaks Rails again.
"Rails master already fixes it" doesn't care the problem; we breaks compatibility.

Breaking compatibility itself is not problem, but we can provide very small benefit for Rails application in 2.7 and 3.0.
We only provide disadvantages in recent versions.
Ractor and types are great milestone for future Rails, but they are not for Rails at this time.

I'm serious about the motivation of upgrading to Ruby 3.0 for Rails users.
I worry that so much.

naruse (Yui NARUSE) wrote in #note-16:

In 2.7 we break large compatibilities, and this tickets breaks Rails again.
"Rails master already fixes it" doesn't care the problem; we breaks compatibility.

In this case, Ruby's behavior resulted in objects that were not internally consistent. Rails has a fair amount of code just to work around the inconsistency , which they will be able to drop once 3.0 is the minimum version (Rails 7?). See https://github.com/rails/rails/blob/1165401ee962aef0aaf81080e3e7dcab522efa40/activesupport/lib/active_support/core_ext/string/output_safety.rb#L248-L253

I appreciate the importance of backwards compatibility. Almost all of my libraries run on Ruby 1.9 - Ruby 3.0. However, I don't think we should skip fixing problems in core Ruby just because it breaks a small part of Rails, especially if fixing the issue in Rails is simple. We should always weigh the costs and benefits when deciding whether compatibility should be broken. That being said, I respect your opinion, and if this experiment causes too many issues, we can revert.

I'll ask the same question I've asked before... Why not deprecate this first?

This gives time to Rails to issue a simple update to the versions that are supported, and in a year or two the behavior can change without breaking anything.

Fixing things is good, but there is no urgency to fix this.

There are far more (intentional and some of them warned before) breaking changes in Ruby 3 than this, so I don't see the point.
I guess Rails backported all the keyword arguments changes to previous major versions?
Then maybe we can do the same for this.

An old release of e.g. Rails 5 already doesn't work on Ruby 3, so there is no point to be compatible with that.
I understand being compatible with the latest Rails 5 release makes sense, though.

naruse (Yui NARUSE) wrote in #note-16:

I'm serious about the motivation of upgrading to Ruby 3.0 for Rails users.
I worry that so much.

I wouldn't worry.
If people upgraded to Ruby 2.7, they'll be happy to update to Ruby 3 which has understandable keyword arguments semantics and many other things.
I think a lot of people are excited about Ruby 3.
If there was a release to worry whether people would upgrade to it it was 2.7, but it seems many people upgraded to it.

Rails Active Support CI against Ruby master branch failed.
Performed git bisect and found it has been triggered since https://github.com/ruby/ruby/commit/58325daae3beefda13ed100782cd19a89cc68771 .

https://buildkite.com/rails/rails/builds/72947#6a6a6523-71a1-4e64-9de2-597a161f0aaa/994-1003

PR to fix it by @matsuda (Akira Matsuda): https://github.com/rails/rails/pull/40663