Ensure all setter methods in the standard library return the value being set

[HertzDevil]

Until the more general #7707 is resolved, this ensures all setter methods always return the value arguments that are passed to them.

The setters were identified using /def (self\.)?([a-z_0-9]+|\[\])=/. Setters inside specs are ignored. One conflicting return type restriction was removed, but it was internal to the compiler (Crystal::Signal.child_handler=).

[bcardiff]

I think the returned type should match the corresponding getter.

So the expressions foo.prop ||= value that is expanded as foo.prop || (foo.prop = value) will not generate unions, and the result will be less confusing IMO.

[bcardiff]

This change is wrong. The size argument and the Array#size getter may have different types.

[Sija]

There's no need for them to be the same. Setters ought to return the given value, not the one actually returned by the corresponding getter.

[bcardiff]

ditto Array#size=

[bcardiff]

ditto Array#size= and others in this file

[asterite]

I wouldn't go this route if we'll eventually solve this at the language level. I can give it another try.

[straight-shoota]

The effort is appreciated, but I honestly don't think this is a good idea. This change is unncessary if we enforce this behaviour in the compiler. It mostly bloats the code.
Sure, it certainly improves the API in many places, but I haven't seen an actual problem with this. So it's IMO not worthy to merge this at the current time.

[straight-shoota]

I recall my previous comment. We're in a different state now. I don't think we can change the language mechanics before 2.0. That would be an inexcusable breaking change.
But we can change stdlib methods to explicitly return the assigned value. These are technically also breaking changes, but that's acceptable because they're fixing bugs. The current return values of these methods are completely unintentional and leak internal implementation.

[asterite]

Why would fixing the return values be fixing bugs, but changing it for every method be a breaking change? It might be worth trying the global change and see how, and if, ir affects the ecosystem.

[straight-shoota]

For stdlib methods we can be sure that the leaking return value is unintended. But third party code might rely on that. Changing this would break the language specification. Changing stdlib methods would only change each method's implicit contract which was never specified.
There could be code that relies on that as well. But it's based on an undocumented implementation detail which turns out to be a bug. In order to fix it, we must break code that (most likely unintentionally) relies on it.

[straight-shoota]

I think we should go forward with this. Unfortunately, this PR has gone out of sync with master. So it needs some catching up.