Joe Tsai

> the method's implementation must be able to indicate that the method is not actually supported. This is one of the driving usages of #21904. Part of the problem with...

Thanks for filing. This is a bug. There are more differences than similarities, that it shouldn't have chosen this particular representation.

For my own benefit, here's a reproduction: https://go.dev/play/p/7u4lcejtNsf

The `motd_stat` file is a legacy `init.d` style script. Here's the more modern `systemd` service script that I've been using: ``` [Unit] StartLimitIntervalSec=0 StartLimitBurst=0 [Service] ExecStart=/usr/local/motd_gen/motd_stat.py WorkingDirectory=/usr/local/motd_gen User=root Group=root Restart=on-failure...

The [v2 json draft proposal](https://github.com/golang/go/discussions/63397) includes a `SyntacticError.ByteOffset` field, which I suspect makes this feature redundant. I think we should defer on changing this until v2 lands.

Try this instead: https://go.dev/play/p/ze0FqocVe-8

According to [RFC 1952, section 2.2](https://datatracker.ietf.org/doc/html/rfc1952#section-2.2): > A gzip file consists of a series of "members" (compressed data sets). Thus, when a gzip member terminates, the parser should correctly check...

The logical extension of this would be that nearly every callsite like: ```go n, err := w.Write(b) ``` would end up being replaced by: ```go n, err := io.WriteAll(w, b)...

Whatever solution is chosen here, I would argue that it should work even if the user explicitly provides duplicate names: ```go logger.LogAttrs( context.Background(), slog.LevelWarn, "fancy message", slog.String("duplicate", "alpha"), slog.String("duplicate", "bravo"),...

> duplicate keys aren't invalid, just less interoperable. Technically you are correct. Under RFC 8259, section 4, duplicate names are essentially treated as undefined behavior. In a possible future major...