Wojtek Mach

@whatyouhide interesting! By _stream_ of `{atom, term}` tuples you mean a _list_ of these right? Or we're talking about lazy streams? I assume it's a list (so this function returns...

RE CI failure, sigh, https://github.com/actions/runner-images/issues/9692.

CI is fixed in #448.

We could have a single function that does connect/request/recv_response/close and it returns {:ok, enumerable}, no conn, it would be something like request/9 or, you know, request/_1_. :)

@whatyouhide yeah, I think this is a good compromise. The only thing that comes to my mind is with a distinct `recv_response/3` we may still support request body streaming before...

That being said I think what we have right now is pretty decent (if I may say so) ```elixir iex> {:ok, conn} = Mint.HTTP.connect(:https, "httpbin.org", 443, mode: :passive) iex> {:ok,...

Yeah see this comment: https://github.com/elixir-mint/mint/pull/447#issuecomment-2258261087. I’m fine with discarding (right now on the branch) or crashing. Lmk!

Thanks for this! I think protocols is the deal breaker for now. This is possible today ```elixir Req.post!(url, json: %{now: Time.utc_now()}) ``` and there's no replacement until Elixir gets JSON...

regarding `:decode_json` option today, I can deprecate it in favour of passing, say, `decode_json: &:json.decode(&1, ...)`, so that's not a big deal.

Or, `decoders: [json: &:json.decode(&1, ...)]`. So yeah, we're good, we have long-term backwards compatible options.