1. 11
  1.  

  2. 1

    Enjoyable read.

    I had not seen tagged structs before. This seems like a really lame language feature, can anyone speak to it? Specifically, why should my struct definition care at all what formats it will be serialized into?

    1. 1

      Struct tags are just meta data that is only accessible via reflection. They can be used for anything you want, but they’re definitely most commonly used for describing how to encode/decode data in the struct in some particular format. Usually the encoding library you’re using will establish a convention to be used. This particular use case prevents you from having to define two structs for every data collection you encode/decode: one that matches the serialization format precisely and another for your code. It also allows you to use the same struct for encoding/decoding multiple formats. This is of course only pertinent when using an encoder/decoder that makes use of reflection.

      In general, I am pretty happy with using struct tags. I’ve built a few libraries that make use of them and they’ve been pretty nice.

      1. 1

        Oh yes, I understand what they do, they are just wrong. Tying my type definition to a particular serialization library is obviously wrong.

        1. 1

          I disagree. It’s just a trade off that not everyone will find appealing. And using a struct tag doesn’t tie your type to a particular library. Convention allows for multiple fields to be specified in a struct tag. I don’t see how this is inherently wrong.

          1. 1

            It is inherently wrong because it conflates concerns. Defining a type and defining how it encodes are separate concerns.

            1. 1

              Defining a type and defining how it encodes are separate concerns.

              I agree. Never said they weren’t. That’s the trade off. In return, you get much simpler—but potentially less flexible—code. In practice it works because library authors respect conventions.