[ruby-core:108021] [Ruby master Feature#18566] Merge `io-wait` and `io-nonblock` gems into core IO

Issue #18566 has been updated by Eregon (Benoit Daloze).


Those methods have been in stdlib for a while, I don't think moving them to core is an issue (their name and behavior is established already).
And I think renaming is not on the table either for compatibility (too high effort/too low gain).

What's the problem with `nread`? It's "how many bytes are available to read", seems fairly obvious. It's not the best name, but that's hardly the only method like that (e.g. byterindex is no better I'd say).
FWIW Java has a similar method: https://docs.oracle.com/javase/7/docs/api/java/io/InputStream.html#available()

Re `ready?` the docs make it clear it's about input so reading (can always improve the docs).

`wait_priority` just needs better docs, that seems clear.

I think we shouldn't keep any methods in the io-wait gem.
Those methods need lots of IO internals (e.g., the C ext includes `ruby/io.h`, which exposes all internal details of `rb_io_t`), and I think it makes no sense to expose the IO internals of all Ruby implementations in that gem just for "not being in core".
Users don't care, if they need these methods they will require it and use them, core or not does not change much for them, but it does a lot for Ruby implementations.
As an example, TruffleRuby does not want to expose IO internals, so it remains free to refactor those as needed.

Those 2 gems (io-wait and io-nonblock) seem extremely unlikely to ever be removed from stdlib/default gems, because they are already needed by many programs.
That means for TruffleRuby we need to either to use the C extension for those gems (but that's a significant overhead for just these few methods), or we implement them in Ruby using TruffleRuby Primitives and then it does not make sense to have that code in a gem (would be exposing internals subject to change).

Another options is to move those gems back to plain stdlib (not a gem). These 2 seem to have very few benefits to be gems, and have many disadvantages due to needing IO internals.
These 2 gems are essential methods to deal with IO, having them as gems is just causing problems IMHO.

----------------------------------------
Feature #18566: Merge `io-wait` and `io-nonblock` gems into core IO
https://bugs.ruby-lang.org/issues/18566#change-96979

* Author: byroot (Jean Boussier)
* Status: Open
* Priority: Normal
----------------------------------------
I think we should reconsider status of `io-wait`, and consider simply merging it into core's `IO`.

According to @nobu it's only a gem for "historical" reasons.

Any non trivial IO code will likely make use of it, and it's just 400 lines of code.

Recently with the extraction of `net-protocol`, it was added add a dependency and that caused Ruby 3.1 compatibility issues with some gems (e.g. with [`mail`](https://github.com/mikel/mail/pull/1439)).

### Proposal

  - Merge `io-wait` into `io.c` for Ruby 3.2
  - Remove `io-wait` as a dependency of all gems maintained by `ruby-core` (e.g. `net-protocol`).
  - Publish a new `io-wait` version that is simply an empty gem.
  - Add a `lib/io/wait.rb` stub, with eventually a deprecation warning.

cc @eregon @headius @mame @ioquatix



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

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