Remove pure JS (non native) io functions from Deno namespace

[lucacasonato]

I propose we remove the following APIs from the Deno namespace, and move them to std:

Types:

• [ ] Deno.Reader
• [ ] Deno.Writer
• [ ] Deno.ReaderSync
• [ ] Deno.WriterSync
• [ ] Deno.Closer

Functions:

• [x] Deno.Buffer (#9793)
• [x] Deno.copy (#11369)
• [x] Deno.iter (#10025)
• [x] Deno.iterSync (#10025)
• [x] Deno.readAll (#9793)
• [x] Deno.readAllSync (#9793)
• [x] Deno.writeAll (#9793)
• [x] Deno.writeAllSync (#9793)

Timeline

I suggest we mark all the APIs we want to remove with @deprecated, and add a deno lint diagnostic for when these APIs are used. In Deno 2.0 we can then remove these APIs.

Reasoning

Code which does not actually require native syscalls should not use Deno namespace APIs as this makes the code incompatible with browsers, even though there is no need for that to be the case. An example of this: https://deno.land/[email protected]/io/streams.ts. This uses Deno APIs, even though no native calls are preformed, making this code unusable in a web browser for no good reason.

[kitsonk]

Why move the types? They are referred to by other built ins that are returned, are they not?

[kitsonk]

Buffer is also mentioned in #9588, we should maybe close that?

[lucacasonato]

Why move the types?

Same reason as to move the functions. Code using Reader / Writer etc does not work when lib is dom instead of deno.ns. IMO if it doesnt need to be a binding (or a type for those bindings) because it can work just fine in the browser, it should not be part of the Deno namespace.

They are referred to by other built ins that are returned, are they not?

The builtins never explicitly return or take a reader/writer after these changes as far as i'm aware. They only return types that implement Reader or Writer. Instead of using implement in the d.ts, we can just specify the read / write methods no the interfaces directly. This would make them implicitly implement Reader / Writer (just like interfaces work in Go).

[timreichen]

@lucacasonato in addition to that: would you be open to rename Deno.iter -> Deno.iterator Deno.iterSync -> Deno.iteratorSync for aligning with the js name like in Symbol.iterator?

[lucacasonato]

No. They are both in the process of being deprecated and will be removed. No reason to rename.

[ry]

I'm in agreement. It's very painful to let web streams (ReadableStream/WritableStream) win over go streams (Reader/Writer). Go streams is plainly more general and vastly simpler. But we must have web streams because of fetch. And having two different and incompatible stream abstractions is worse than having one shitty one.

One of the original intentions of Deno was to correct the abysmal streams implementation in Node. I think Go provides a very elegant and complete solution with a beautiful library of combinations.

[MierenManz]

We just have to hope that there will be a webstream2 at some point in the future that is based on go streams :/

[nayeemrmn]

Just to clarify, this issue was about a purely symbolic refactor to remove the explicit type definitions of Reader and Writer in favour of just defining the read() and write() methods on their implementers. This is logical because there are no stable built-ins that accept these interfaces, only ones that return them. A one sided protocol so to speak. Since they do have consumers in std, it would be more appropriate to have the definitions there.

Why @ry mentions above is the result of more recent discussion to remove even the concrete read() and write() methods in favour of web stream APIs. We should continue in #11018 for that.

[kt3k]

We're removing the usages of Deno.Reader, Deno.Writer, ... from std in denoland/deno_std#3030

[iuioiua]

Types:

• [ ] Deno.Reader
• [ ] Deno.Writer
• [ ] Deno.ReaderSync
• [ ] Deno.WriterSync
• [ ] Deno.Closer

Perhaps, 2.0 is a good time to deprecate these interfaces. A counterargument is fast streams implementations are still in progress, and I wouldn't expect people to be happy with the deprecation unless the performance of the alternative was on par or better.

[kt3k]

What to do about Deno.Seeker and Deno.SeekerSync?

[kt3k]

There seem a few concerning points to this move:

• There seem no alternative way to support synchronous I/O using ReadableStream based APIs.
• The support of seek behavior will be awkward though it's still possible to perform with mixed usage of ReadableStream and existing seek() method

[kt3k]

sync behavior might be implemented as FileSystemSyncAccessHandle in the future

seek is available in FileSystemWritableFileStream, but I couldn't find a way to seek during reading in Web APIs

[iuioiua]

Update: std/log no longer depends on Deno.Writer. See: https://github.com/denoland/deno_std/pull/4021

[iuioiua]

What to do about Deno.Seeker and Deno.SeekerSync?

What do we think about this? Best to come to a decision before Deno v2. Related: Deno.seek() and Deno.seekSync() were deprecated in Deno 1.40.