[kenshaw]

I feel very strongly that type safety is of paramount importance in development, and "oneof" (and other similar constructs) in protocol design breaks fundamental ideas of type safety. It's a feature of the IDL that doesn't translate well to the actual implementing language, is not strictly necessary as the same thing can be accomplished through other designs that have an added benefit of being more explicit, both to the implementer and to the consumer.

[atombender]

No, "oneof" increases type safety. "oneof" describes mutually exclusive fields. For example:

  message Filter {
    oneof kind {
      Tags tags = 1;
      IPRange ipRange = 2;
    }
  }

With this in place, a client has to check the type of the filter in order to access the actual filter:

  switch t := f.Kind.(type) {
    case *Tags:
      // ...
    case *IPRange:
      // ...
  }

Without it, you can get into a situation where it's possible to create invalid combinations:

  message Filter {
    string type = 1;
    Tags tags = 2;
    IPRange ipRange = 3;
  }

Now you can accidentally end up with code like this:

  f = Filter{}
  f.Type = FilterType_Tags
  f.IPRange = IPRange{}

or:

  if f.Type == FilterType_Tags {
    useFilter(f.IPRange)
  }

[jzoch]

You believe in type safety yet refuse to let an IDL dictate a type at compile time?

[LOLOLOLO1]

"oneof" construction is here for two reasons:

1. It enhances readability 2. It would be a surprise to you: oneof actually enhances type safety. It is just lacking type system of Go where you cannot express the feature and thus loses type safety.

[xiphias2]

Let me guess: you are talking about types and type safety without learning type theory and type algebra. You are just throwing out 1 of the two basic building blocks of type algebra and sticking to your point even though everybody tells you how important it is. Anyways it's ok if you want to be Go specific, this is totally fine.