Roger Peppe

@bcmills the point I'm trying to make is that when the limit isn't exceeded, we shouldn't see an error from `io.Copy` at all. In my eyes, it makes most sense...

The more I think about it, the more I think that the original goal isn't nicely attainable just by adding an `Err` field to the `LimitedReader` struct. `LimitReader` has the...

> That is: if you don't try to read past the limit at all, then you don't get the “limit exceeded” error. That's fine AFAICS. In that case, the limit...

> Then you check the n returned from io.Copy against the actual limit But that means that you can exceed the limit when copying, which surely isn't great?

`MaxBytesReader` sounds exactly like the behaviour that `LimitReader` currently implements, I think (the whole point would be that it _doesn't_ restrict the number of bytes read from the underlying reader...

The actual use case we're thinking of is syntax highlighting in the [CUE Central Registry](https://registry.cue.works/) source view (not yet landed yet, so I can't link to an actual example). The...

> Coincidentally, I just created a https://github.com/alecthomas/chroma/pull/1144 last week that switches Chroma to stdlib iterators. It would be a breaking change though, so I'd need to cut a v2. In...

I came here to submit a similar example. If the thing that staticcheck says is unused really _was_ unused, then the program would still compile if it was removed, but...

One other thought: a possibly simpler way to write `delegatingLexer.Tokenise`: ``` func (d *delegatingLexer) Tokenise(options *TokeniseOptions, text string) (Iterator, error) { tokens, err := Coalesce(d.language).Tokenise(options, text) if err != nil...

Here's an example that demonstrates that the `+` operator really does inappropriately drop down to float precision: it's not just an artifact of the export/display logic: ``` exec cue export...