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

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

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).

@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?

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

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.

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

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.

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

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.

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

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

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

Update: std/log no longer depends on Deno.Writer. See: denoland/std#4021

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.

All of these APIs are no longer available as of #25213 and Deno 2.0.0-rc.0.

We'll be also moving Deno.Seeker[Sync] into @std/io/types of the Standard Library.