Jonathan Hall

The comments issue should be resolved with a727581fef44aa7abc4968d658d8fef63ebbe071 (Thanks @mvdan for the help on Slack!)

See https://github.com/flimzy/gofumpt/commit/64e649574265f1d53456df83257cee690b5a36c7 for what this new transform does on the gofumpt repo itself. I'll do further testing on a larger collection of repos when time permits.

I've run this change against the stdlib, as well as the repos in [this list](https://github.com/mvdan/corpus/blob/master/top-100.tsv). I found [two panics](https://github.com/mvdan/gofumpt/issues/288), which already existed in gofumpt prior to this change. Otherwise, the...

Anything else before merging this one, @mvdan ?

I see that CI is failing, and probably needs to be updated. For the tests in this PR to be meaningful, we'll alsoneed to run tests against Go 1.21 (since...

> The client sending the request knows the length of each file Not necissarily. > That's not to say you're going to get multipart/related to work, but you can enjoy...

> In what case / scenario are file sizes not known by the source/client machine? At the risk of soundind trite, any time the source is not a raw disk...

> The machine that sent that HTTP request knows the file length Again, not necissarily. I gather that you've not done a lot of stream-based programming over HTTP or otherwise.

@ronnieroyston I'm curious the point you're trying to make here? Is it just that you don't see a need for this feature?

No. I'm looking for exactly what the issue describes. The ability to use `multipart/related` without specifying a file size for each attachment in the JSON preamble. I'm still unsure what...