No variable-length fields are currently supported. I hadn't realized at first that Writing a []byte doesn't write the length; the user must do this. Now the limitations make more sense.

That said, preceding []bytes and strings with a varint-encoded length seems kinda obvious.

I retract the request to support []byte and strings as struct fields, since it's at the wrong level of abstraction. encoding/gob makes more sense for that.

It might still make sense for encoding/binary to support strings in the same way as []byte, though.

That said, preceding []bytes and strings with a varint-encoded length seems kinda obvious.

Which varint encoding? Or fixed32? Or fixed64? And so on.

encoding/binary handles []uint8 (akak []byte) because it handles the general case of slice of fixed-size-integer. That is, the same code handles []uint16, []uint32, and []uint64. While we could add string, it would be a special case and one that I think would confuse people more than it would help.

Because of the general case, it would be silly to remove support for []uint8 as a special case. But at the same time I don't think it makes sense to add a special case for string. Instead of binary.Write(w, binary.LittleEndian, s), use w.Write([]byte(s)) or io.WriteString. That's much clearer and doesn't make one wonder how exactly it's important that the string is written in little-endian format.