Explicitly annotate existential usage of Message with the existential any keyword.

[mrabiciu]

This PR separates out the addition of the existential any from #1504 into its own distinct PR for easier consumption.

Context: #1504 adds Self constraints to Message with the addition of static var _fields: Field<Self>. With this change the swift compiler will require uses of the existential Message type to be explicitly annotated with the any keyword. This keyword is currently optional for existential types without Self constraints however it will be required in swift 6.

[thomasvl]

Can you expand the description for why this is needed (for history, etc.).

And looking at the other PR, public struct Field<M: Message> { ... } doesn't both with any there, which seems to say not all uses of Message need to change to any Message, so what were the concrete requirements and are all these changes actually needed?

[mrabiciu]

Updated title and description

[FranzBusch]

This keyword is currently optional for existential types without Self constraints however it will be required in swift 6.

This statement is no longer true. The language workgroup has recently put out a post where they stated that ExistentialAny is no longer going to become a default feature in Swift 6. So for now we should put this on hold.

Can you explain why your other PR needed this to be changed everywhere?

[mrabiciu]

This statement is no longer true. The language workgroup has recently put out a post where they stated that ExistentialAny is no longer going to become a default feature in Swift 6

Ah TIL good to know!

Can you explain why your other PR needed this to be changed everywhere?

I'm adding a static var _fields: [Field<Self>] { get } property to the Message protocol, which means this protocol now has Self constraints. With this change swift requires existential uses of Message to be explicitly annotated with the existential any.

Without this the compiler complains Use of protocol 'Message' as a type must be written 'any Message'

[tbkka]

I see a lot of any Message.Type and similar in here. I believe that is wrong -- Message.Type is not being used as an existential here, so the any is not appropriate.

[mrabiciu]

I see a lot of any Message.Type and similar in here. I believe that is wrong -- Message.Type is not being used as an existential here, so the any is not appropriate.

@tbkka All of the places that I've annotated with any were labeled by the compiler as required when combining with my changes from #1509. Including uses of Message.Type.

Just like how trying to use Equatable.Type would also require an any. I think for this to not be an existential use of Message you'd need the above to be expressed as

public mutating func decodeExtensionFieldsAsMessageSet<M: Message>(
    values: inout ExtensionFieldValueSet,
    messageType: M.Type
)

[tbkka]

Yep. My mistake.

[FranzBusch]

In general, I am happy with adopting ExistentialAny in this package since the language steering group has just deferred it to the next language revision. However, for consistency reason I would like to enable the upcomingFeatureFlag in our Package.swift then and just stick it everywhere. This way the compiler is going to enforce it for us.
@thomasvl @tbkka WDYT?

[thomasvl]

In general, I am happy with adopting ExistentialAny in this package since the language steering group has just deferred it to the next language revision. However, for consistency reason I would like to enable the upcomingFeatureFlag in our Package.swift then and just stick it everywhere. This way the compiler is going to enforce it for us. @thomasvl @tbkka WDYT?

Having the validation sounds good to me.

[tbkka]

@tbkka WDYT?

Sounds like a good plan to me. Let's do that.

[mrabiciu]

I found a workaround for this in #1504 so this is no longer necessary for me. LMK if I should close this. I'm happy to merge it too if you'd like.

[thomasvl]

I think we're good landing this, just need to do @FranzBusch 's suggestion to enable the workings in the Package.swift file.