[ruby-core:98362] [Ruby master Misc#16890] [Ruby Keywords and Ruby 3.0 release] Feedback to matz and the ruby core team

Issue #16890 has been updated by shevegen (Robert A. Heiler).


The discussion at https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument-pain-point/74980/2
is already quite long, and I do not intend to add to the discussion there, largely because I think 
it may be difficult for matz and the core team to follow everything easily (it's quite a long 
thread already).

Some folks gave specific feedback, and suggestion; there was one particular proposal to delay 
ruby 3.0. I would rather like to NOT see ruby 3.0 release delayed and I think most of us want
a xmas ruby release. We are like little kids, well, many of us. ;)

More specifically, to the keywords situation: I am not really affected directly, because I don't
really use ruby keywords nor do I need them (I tend to stick to the matz ruby oldschool style
so perhaps I am just getting old finally, but I like oldschool ruby :D).

I have, however had, noticed that there are LOTS of warnings generated by other programs. 

A new rails create command triggers a lot of warnings too. And I think, while warnings are
not necessarily harmful per se, they can be quite annoying and verbose. I believe that this
is actually a real problem in the sense that ruby users may, at the least right now, get
a "too chatty" ruby. I am not saying that other issues don't exist, since evidently it
takes others time to re-write code etc..., which I am aware of is never a lot of fun. But
I am mostly just explaining my own particular case - I am not really affected directly,
but indirectly (with the messages) - not a real pain point for me at all, but a bit 
spammy and noisy.

Matz gave specific suggestions, options, asked for opinions too.

I have no particular strong opinion either way; I do agree that in the long run it is
better to have a keyword argument situation in ruby that is simple to understand and
simple to use, so it should be changed. But perhaps it should not be changed for 
ruby 3.0 (and then there may always be people who want a change, but when everyone
has a different opinion, you can't really make everyone equally happy at the same
time).

So I am mostly neutral, with perhaps a tiny bit in favour of considering to delay
the changes to post ruby 3.0 release.

I think that independent of this, it may be a good idea to consider how to change
ruby if change means that it may require ruby users to adjust their code (e. g.
incompatible changes). Perhaps some release process that covers a range of ruby
releases, like:

3.0 to 3.2:
  1 - 2 big changes
3.2 to 3.4:
  1 - 2 big changes

And so forth. That is just an example, to try to find some way to make the change
sets smaller or something like that.

By the way, I think one or two among the ruby core team, also maintain some gem
with backwards-compatible code, e. g. where new features can be used in older
rubies. Perhaps we could think about something like this for "future" ruby too,
a bit similar to the frozen string literal change (but I am not necessarily
 saying we should use lots of magic syntax in # comments; I mean this more 
in general).

----------------------------------------
Misc #16890: [Ruby Keywords and Ruby 3.0 release] Feedback to matz and the ruby core team
https://bugs.ruby-lang.org/issues/16890#change-85630

* Author: shevegen (Robert A. Heiler)
* Status: Open
* Priority: Normal
----------------------------------------
As some folks may already have read/heard, matz is asking for feedback.

He specifically asked this in regards to the rails devs, and the rails ecosystem
but this may be relevant to all ruby users.

You can read his ideas here:

https://discuss.rubyonrails.org/t/new-2-7-3-0-keyword-argument-pain-point/74980

In this introduction I do not intend to add anything more really; ioquatix
suggested to (also) create a specific tracker here.

I will add my personal opinion after this.



-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>