Move runtime to FoundationEssentials

[madsodgaard]

As per the recent forums post on the import FoundationEssentials, this PR implements the strategy described.

The generator now generates the conditional essentials import.

The only remaining part after this is to do something about the BinaryDelimited APIs which use InputStream and OutputStream

Fixes #1756

[thomasvl]

You'll need to do a make reference to update those also. Then I'll kick off the workflows.

[madsodgaard]

@thomasvl Missed that, thanks!

[thomasvl]

@FranzBusch I'm assuming semver/patch since there is still the one import Foundation to resolve, so the overall transitive imports haven't changed.

[FranzBusch]

@FranzBusch I'm assuming semver/patch since there is still the one import Foundation to resolve, so the overall transitive imports haven't changed.

Yeah that sounds right to me

[madsodgaard]

@FranzBusch anything missing here?

[FranzBusch]

LGTM. In a follow up can you add a CI check that ensure we are not regressing this?

[madsodgaard]

@FranzBusch Yeah sure. We still need to address the BinaryDelimited APIs. Did you have a preferred approach? So, either a default trait that enables them or a non-default trait that disables them?

[FranzBusch]

@FranzBusch Yeah sure. We still need to address the BinaryDelimited APIs. Did you have a preferred approach? So, either a default trait that enables them or a non-default trait that disables them?

We can't do the latter. A trait must never take away API it can only add API. Having said that I think the only way forward is to introduce a default trait that moves these APIs behind it. That can be done once when adopting traits. @thomasvl @allevato are there any other pieces that we see valuable to move behind traits so that they become opt-in for developers?

[allevato]

@thomasvl @allevato are there any other pieces that we see valuable to move behind traits so that they become opt-in for developers?

The custom FieldMask operations (everything but the _CustomJSONCodable conformance, I believe, which is required for correctness) have come up in our conversations as good candidates. The vast majority of folks will never use them. We've discussed the possibility of even factoring them out into their own separate sidecar module before.

[thomasvl]

@thomasvl @allevato are there any other pieces that we see valuable to move behind traits so that they become opt-in for developers?

The custom FieldMask operations (everything but the _CustomJSONCodable conformance, I believe, which is required for correctness) have come up in our conversations as good candidates. The vast majority of folks will never use them. We've discussed the possibility of even factoring them out into their own separate sidecar module before.

For completeness - any the supporting files that are needed for those apis would be gated.

As far as binary delimited, do we also do the async sequence part or just the Foundation part?

As a follow up to this, since we have package visibility, when we do a breaking change, could we move these things gated with traits to secondary modules? The delimited support and the FieldMask additions are all things that could be built with package visibility, we just didn't have it at the time. So it seems like eventually it might be nice to switch to that instead of traits.

[thomasvl]

@FranzBusch I'm assuming semver/patch since there is still the one import Foundation to resolve, so the overall transitive imports haven't changed.

Yeah that sounds right to me

@FranzBusch, I noticed you switched from patch to minor, what was the reason? Just because when all the work is done to finally switch to FoundationEssentials? i.e. - even though the repo still depends on it, just make it align when it finally is removed?

[FranzBusch]

I would suggest we move the trait discussion into a separate PR @madsodgaard are you happy to open that PR and drive the discussion there?

As far as binary delimited, do we also do the async sequence part or just the Foundation part?

I would just move the Foundation dependent part since the rest is pretty minor right? Not sure if we get much from moving it behind a trait

We've discussed the possibility of even factoring them out into their own separate sidecar module before.

We can do that down the line but it is a breaking change whereas the trait move would allow us to do it in a non-breaking migration once.

@FranzBusch, I noticed you switched from patch to minor, what was the reason? Just because when all the work is done to finally switch to FoundationEssentials? i.e. - even though the repo still depends on it, just make it align when it finally is removed?

Correct. I just wanted to make sure we have one PR that has minor on it since that follows the ESG guidance. At best we group all of these PRs in the release notes under minor.

[madsodgaard]

@FranzBusch Yeah, I can follow up on the traits in a different PR