Split generated code into multiple files

[kgominyuk]

Code generation can significantly bloat the app size in large projects. Splitting generated code into multiple files allows teams to decide which features they want to include in their code.

Before

my.proto
  ↓
my.pb.swift

After

my.proto
  ↓
my.pb.swift
my.pb.hashable.swift
my.pb.nameproviding.swift

[tbkka]

In the SwiftProtobuf sources, we have the convention that a file declaring an extension of some type gets named "Type+Protocol.swift"

I wonder if some variant of that convention would be more appropriate here? I think that would end up giving us ".pb+Hashable.swift" which is admittedly a little weird looking. But at a minimum, Hashable and NameProviding in these filenames should be correctly capitalized.

[kgominyuk]

my.pb+Hashable.swift
my.pb+NameProviding.swift

or

my+Hashable.pb.swift
my+NameProviding.pb.swift

?

[thomasvl]

Since some of these seems like they will only have protocol additions, do we run the risk of exposing problems like #1061 again?

With #18 and #1240, one of the concerns can be how do things then present to developers. If the runtime still exposes the TextFormat and JSON methods of all messages, then someone not linking the right files will still build, and they would get a odd runtime failure. And it isn't just for the root message type, it would be an error from any of the transitive message types. So moving these to extensions means code can compile and fail at runtime which is sorta counter what I'd normally expect for a lot of Swift. It seems like it would be better if there was an way to ensure a developer couldn't try to call the methods if the support is going to be missing (atleast for the topmost message).

[kgominyuk]

So moving these to extensions means code can compile and fail at runtime which is sorta counter what I'd normally expect for a lot of Swift.

What do you think about these things:

1. Moving func jsonString() into extension Message where Self: _ProtoNameProviding
2. Add something to the _ProtoNameProviding generated code that checks at compile time that all message properties conform _ProtoNameProviding. For example:

  private var _protobuf_ProtoNameProviding_conformance: [SwiftProtobuf._ProtoNameProviding] {
    return [
      _property1,
      _property2,
    ]
  }

In theory it should not affect binary size, since this variable won't be used anywhere.

[thomasvl]

Ultimately this is up to the Apple folks as they own the repo; my thoughts -

• I worry moving any apis based on conformances might actually trip the breaking api checks, so that might rule them out.
• With the other works being done, we've been looking at some SwiftProtobuf usage within google, and sadly, some folks are dependent on things like description on enums in cases I don't think they realize, and that ends up forcing a connection all the name to the name providing to get the strings they are expecting.
• Lastly, I'm not really sure how free standing these files are. My fear is some of the things going into external files are actually always go to have to be compiled/linked for things to work, so I worry splitting them off might give the appearance the could be left off when they really can't.

But as I mentioned, this is all up to the Apple folks in the end on what they'd like to do.

ps - I'll also add that #1804 recently landed that shrankthe binary sizes some, and #1806 & #1807 also should have helped reduce some runtime costs.