Feature #5009: Bang method (!) consistency in Ruby 2 API

This is a common misconception about the use of bang methods in Ruby. Bang does not indicate that a method mutates its receiver, merely that it should be used with caution. A good writeup on this can be found here: http://dablog.rubypal.com/2007/8/15/bang-methods-or-danger-will-rubyist From the conclusion: > If you let go of the notion that ! means destructive, and if you think through the naming and pairing of dangerous and non-dangerous methods, you’ll see how valuable a flag the ! can be.

If this is a proposal for renaming aforementioned methods, it will break a lot of existing code. If the idea is to add aliases, it will introduce Ruby 2-specific methods that will not be used for a really long time by developers who want to maintain compatibility with multiple Ruby versions.

-1 ActiveRecord's save/save! is also a good example.

Just for the record, there is one method that I think we should add a bang if we still could, and this is String#force_encoding. The reason isn't that it changes String itself (which it does), but that I have come across quite some places where I use string.dup.force_encoding. It would have been best to use force_encoding! for what's now force_encoding, and force_encoding for the copying variant. But I agree with both Michaels and Yui that it's too late to change.

Martin Dürst wrote: > Just for the record, there is one method that I think we should add a bang if we still could, and this is String#force_encoding. The reason isn't that it changes String itself (which it does), but that I have come across quite some places where I use string.dup.force_encoding. It would have been best to use force_encoding! for what's now force_encoding, and force_encoding for the copying variant. But I agree with both Michaels and Yui that it's too late to change. About String#force_encoding, I think add an alias named String#encoding= may be good. But it's still under consideration.

Interesting, the Rails' save/save! example makes sense. And why worry about keeping backwards compatibility? Ruby 2 can break it, in the interest of removing cruft.

• Status changed from Open to Closed

Close this; force_encoding is another problem.