1. &io.Data may not be a good abstraction 2. Writer interface

[bobzhang]

1. From what I can tell, it only supports 3 kinds of data: Bytes, String and Json where String and Json are used most. It was introduced to allow some overloading so that

@http.post("url", data)
@http.post("url", { "xx" : "json"})

but this does not work in practice so that we have to write @http.post("url", ({"xx" : "json"} : Json)) which is not better than
@http.post_json("url", {"x" : "data"}) when it could be more efficient or more redable.

it looks to me that either

@http.post("url", String("..."))
@http.post("url", Bytes("..."))
@http.post("url", Json("..."))

or

@http.post("url","...")
@http.post_bytes("url","...")
@http.post_json("url", "...")

they are both more readable and can be more efficient than the current interface
2.

pub(open) trait Writer {
async write_once(Self, Bytes, offset~ : Int, len~ : Int) -> Int // --> async write_once(Self, BytesView) -> Int
async write(Self, &Data) -> Unit = _
async write_reader(Self, &Reader) -> Unit = _
#deprecated("use write instead", skip_current_package=true)
async write_string(Self, StringView, encoding~ : Encoding) -> Unit = _
}

[duobei]

Looking at the current usage, the type inference limitation makes &io.Data harder to use than anticipated — you still need explicit annotations like ({"xx": "json"} : Json), which defeats the purpose of the overloading.

My preference would be named functions (your second option):

@http.post(url, body)        // String
@http.post_bytes(url, body)  // Bytes  
@http.post_json(url, body)   // Json (handles serialization internally)

Reasons:

• Explicit and discoverable via IDE autocomplete
• No type annotation noise at call sites
• &io.Data can be kept as an internal implementation detail rather than a public API surface
• Consistent with how most HTTP libraries in other languages handle this (Go's http.Post vs http.PostForm etc.)

For the Writer interface, write_once(Self, BytesView) seems clearly better — BytesView already encapsulates offset+length, simplifying the trait definition and making it more idiomatic.

Happy to open a PR if this direction sounds right.

[Guest0x0]

For @io.Writer, splitting .write(..) into .write_binary(..)/.write_text(..)/.write_json(..) looks good to me. But that would enforce us to also split @http.put, @http.post, @fs.write_file etc. into multiple API, which is my main concern here. Maybe we could split JSON out only, leaving @io.Data implementation forString, Bytes, StringView and BytesView unchanged?

For the Writer interface, write_once(Self, BytesView) seems clearly better — BytesView already encapsulates offset+length, simplifying the trait definition and making it more idiomatic.

write_once is special because it is a low level API used to connect with the underlying IO interface. It is intended to be implemented rather than called directly. The biggest problem with write_once is that it does not ensure all data are written, which is usually undesirable. @io.Writer::write, on the contrary, will loop until all data are successfully written.

With this in mind, the ergonomic of write_once does not really matter because users shouldn't call it directly. In fact write_once is semi-intentionally made ugly so that people won't misuse it accidentally.