Remove references to RawMessage

[tamird]

The code contains a few references to this type, including type raw interface { Bytes() []byte } which is supposed to be implemented by RawMessage. Unfortunately, that method signature is not as uncommon as one would hope, which can cause bad interactions when that function is implemented on generated structs or their constituent fields (e.g. via github.com/gogo/protobuf's customtype option).

My question is: is RawMessage still a thing? If yes, what is it? If no, would you accept a PR removing "support" for it?

cc @dsymonds

[bcmills]

It's an internal thing. It is supposed to allow for certain functions (e.g. proxy servers) to work with serialized protocol messages directly without the overhead of marshaling and unmarshaling.

I agree that the interface we use to detect it is awkwardly broad.

[bcmills]

(We can't remove it, but perhaps we can make it less prone to collisions.)

[tamird]

Does it need to stay an interface? I could imagine replacing raw with type RawMessage []byte. What do you think?

[bcmills]

It has to correspond to some exported concrete type somewhere, or else nobody can use it.

It might make sense to promote to a concrete type into the proto package itself, though.

[tamird]

Yeah, I meant github.com/golang/protobuf/proto.RawMessage. I'll send a PR.

[bcmills]

The proposed change would need a bit of a complicated internal migration. Unfortunately, I don't think this will work as a PR (sorry!).

[tamird]

No problem. What can I do to help?

[tamird]

Hello. Now that dev is a thing, is there something to be done to move this forward? Is it even still a problem?

[dsnet]

I'm out-of-office for 2 weeks. I'm not going to think about this till I get back.

[dsnet]

Support RawMessage was a gross hack that I wish was never added. I'm okay with changing the signature of the internal type to be something like ProtoRawBytes() to avoid conflicts and define that on the internal RawMessage type.

@bcmills, do you forsee any issues with that?

[bcmills]

None that I can immediately think of.

[dsnet]

Alright, I'll work on making the appropriate changes internally and push it to dev.

[tamird]

(this issue has remained open because #482 was merged to dev, and master is still the primary branch).

[dsnet]

Closing this as the merge work will be tracked in #479.