SE-0335: Introduce existential `any`

Nickolas_Pohilets · 2021-12-19T14:04:10.946Z

Douglas_Gregor:

I can provide the background here. We ended up doing this when implementing Sendable in the standard library, because it depends on the feature being in the compiler as well, like this:
#if <some check for marker protocols>
@_marker protocol Sendable { }
#else
typealias Sendable = Any
#endif
It allowed downstream clients to use Sendable as a generic constraint and also write conformances to Sendable , even with older compilers that couldn't handle the definition.

Is this still relevant? Reading the source code, that's not what I see. Am I looking in the wrong place?

benrimmington · 2021-12-19T19:59:50.047Z

Another recent example:

github.com

apple/swift/blob/3ec0413aa79248bc73852081f9ac7bf5e8fcecbf/stdlib/public/core/Pointer.swift#L13-L17


      
          #if SWIFT_ENABLE_REFLECTION
          public typealias _CustomReflectableOrNone = CustomReflectable
          #else
          public typealias _CustomReflectableOrNone = Any
          #endif

hborla · 2021-12-20T15:42:58.954Z

100mango:

Would You mind telling me the relationship between SE-0335 and Generalized existential?
If we have the support with Generalized existential, do we need SE-0335 ?

This proposal is orthogonal to generalized existentials. This proposal adds an explicit keyword for writing existential types, but it does not allow you to express additional constraints on existential types. Similarly, generalized existentials would not give us an explicit, searchable keyword for writing existential types.

Douglas_Gregor · 2021-12-21T19:17:06.400Z

Nickolas_Pohilets:

Is this still relevant? Reading the source code , that's not what I see. Am I looking in the wrong place?

The technique remains relevant, even if the compatibility window for needing this for the specific marker protocol Sendable has passed.

Doug

Nickolas_Pohilets · 2021-12-22T17:46:19.698Z

Moved to a separate thread - Introduce existential `any` - avoiding inconsistency around `Any` and `AnyObject`

xwu · 2021-12-22T18:14:39.159Z

As John mentioned above, this is a proposal review; can we split this off to a separate discussion thread?

Lantua · 2021-12-28T20:21:08.689Z

hborla:

The reason why any is not required on Any is because it's redundant, not because any is inherently meaningless for unconstrained existential types.

hborla:

1-877-547-7272:

If you have a type alias to Any or AnyObject , do you have to use the any keyword to declare an existential?

I think the answer should be no, because that would lead to really weird inconsistencies with associated type inference.

If I read this correctly, does that mean we can only declare typealias Foo = Any, and that declare Foo as both constraint and existential type? Particularly, can I do this?

typealias Foo = Any

protocol P1: Foo { ... }
func bar(foo: Foo)

I think the more important part about typealias is that it now separates existential aliasing from constraint aliasing. Breaking that property would make refactoring non-trivial. If for example we original used typealias Foo = any and use them as both constraint and existential, such as the code above, then changing Foo to anything else, e.g., Foo = Codable or Foo = any Codable would break the codebase.

That why I think the important part is that we can immediately tell from typealias whether it is aliasing types, constraints, or existential. Maybe we can instead disallow any Any only outside of typealias?

On that note, I think the Any and AnyObject interaction with typealias could be better clarified in the proposal.

For motivation, I think we should focus more on the capability differences between generic and existential. I don't think people are bitten as much about performance (nor are they particularly concerned). It's more important that generic can

use static members,
conform to the itself, or anything really,
access associated type, and
convert to existential,

while existential can only support different member types at run time* at the cost of everything above. So most likely one would use generic when they mean to use unspecified type conforming to certain constraints. The proposal did include the associatetype portion, so we can expand a bit more on that.

* Theoretically, we can add openExistential to convert existential to generic types, but then you're still more likely to prefer to use generic type directly for performance reasons.

Overall, I doubt a mere keyword would make it obvious all the nuance between different choices (existential vs generic vs opaque), but I find the separation between constraint and existential invaluable. Especially since existential behaves much more like concrete types and generics than protocol constraints.

John_McCall · 2022-01-04T18:35:15.764Z

I think the proposal should clarify that, like their base types, Any.Type and AnyObject.Type will also get special behavior to be treated as existential.

TheDeanosaurus · 2022-01-05T15:10:24.620Z

I'm with you on this.

-1

It feels so much like a step backward in the language (and boy it sure looks an awful lot like id<SOMEProtocol> from the yesteryears of Objective-C). I don't see the benefit other than "warning them that what they're doing is expensive and sub-optimal".

... but the language makes existential types too easy to reach for, especially by mistake...

Ok? So are we going to hand-hold programmers with all memory issues now? Seems like not a good place for the language to take over the architecture. Also "too easy"? Isn't that the point of how it was written in the first place?

Lantua · 2022-01-05T19:18:18.157Z

Sorry to be pinging this, but could someone clarify this part?

Lantua:

Particularly, can I do this?

typealias Foo = Any

protocol P1: Foo { ... }
func bar(foo: Foo)

hborla · 2022-01-05T20:03:16.083Z

Thanks for the ping!

I thought about the use case for typealiasing Any a bit more and I think this example should be the same as other type aliases that can be used as generic constraints:

typealias Foo = Any

protocol P1: Foo { ... }
func bar(foo: any Foo)

Otherwise, when the type alias switches from Any to e.g. Sendable, the code would break (under a language mode where any is required). The implementation already knows how to infer any specifically for associated type inference, and we could keep that behavior around for Any and AnyObject under the language mode where any becomes more strict, but this would leave a couple weird inconsistencies:

protocol P {
  associatedtype A
}

struct S: P {
  // this is a type witness, so it has to be existential
  typealias A = Any

  func generic<T: P>() -> T.A: A { ... } // error, `A` is really `any Any` which isn't a valid conformance requirement
}

This inconsistency is only an issue if the type witness is explicitly written with a typealias. We can fix this by always requiring any for explicit type witnesses, even for Any and AnyObject, like you suggest. This also means getting rid of the any Any warning, which I'm very indifferent about anyway, and it seems like some folks in this thread would prefer to write any Any for consistency. And FWIW, this example is super contrived and I don't imagine that using Any or AnyObject as a type witness is particularly common.

Lantua:

I think the more important part about typealias is that it now separates existential aliasing from constraint aliasing. Breaking that property would make refactoring non-trivial.

In the vast majority of cases where a typealias is used as both an existential and a conformance constraint, the refactoring amounts to adding any in front of the type alias name where used as an existential. It's only in the case where a type alias is used for both and it satisfies an associated type requirement that the type alias must be split into two different ones (once any is required) because a protocol is not a valid type witness. This case seems pretty rare, and the transformation still seems straightforward enough to be performed by a migrator.

Lantua:

On that note, I think the Any and AnyObject interaction with typealias could be better clarified in the proposal.

I agree. I'll clarify this behavior in the proposal.

Lantua · 2022-01-05T20:38:49.173Z

Thanks for clarification, it's much clearer now.

In this case, since we're treating typealias Foo = Any as protocol, we lose the ability to directly make an alias to its existential typealias Bar = any Any. The workaround is simple, though; we can just do

typealias Foo = Any
typealias Bar = any Foo

so it's not particularly a problem whether we reject direct Any existential in type alias or specifically allow any Any in there.

However, since we might be allowing/requiring any Any in associated types. It might be better to make the rule instead that, any is required for all (existential) type aliases, even for Any. That might be an easier rule to work with.

hborla:

I don't imagine that using Any or AnyObject as a type witness is particularly common.

Agreed. This should be a pretty rare occurrence. I don't have a strong opinion either.

hborla:

It's only in the case where a type alias is used for both and it satisfies an associated type requirement that the type alias must be split into two different ones (once any is required) because a protocol is not a valid type witness.

I agreed that it seems automatically migratable.

I was thinking about the special case for Any after any is required, which I assumed that its type alias would remain as both existential and protocol. Since that's not the case, please kindly ignore it.

xwu · 2022-01-06T00:56:21.608Z

hborla:

I thought about the use case for typealiasing Any a bit more and I think this example should be the same as other type aliases that can be used as generic constraints:
typealias Foo = Any

protocol P1: Foo { ... }
func bar(foo: any Foo)
Otherwise, when the type alias switches from Any to e.g. Sendable , the code would break (under a language mode where any is required).

I would urge you to maintain the rule that a typealias to Any can continue to serve as both protocol constraint and existential type without warning. As @Lantua points out, otherwise a user cannot typealias existential type Any without jumping through hoops since you also propose to disallow the spelling any Any.

hborla:

This also means getting rid of the any Any warning, which I'm very indifferent about anyway, and it seems like some folks in this thread would prefer to write any Any for consistency.

That definitely suffices as an alternative resolution to the problem though :)

gwendal.roue · 2022-01-06T13:58:42.672Z

xwu:

I would urge you to maintain the rule that a typealias to Any can continue to serve as both protocol constraint and existential type without warning.

And let's make sure, at the same time, that we support the technique described here, by not emitting any warning for any Foo even if Foo is an alias to Any:

#if swift(>=5.5) && canImport(_Concurrency)
public typealias Foo = Swift.Sendable
#else 
public typealias Foo = Any
#endif

Karl · 2022-01-06T15:19:30.105Z

By the way, when discussing changes to Any, there is one secret/magical use-case that I hope is maintained:

typealias IsRandomAccessCollectionOfIntegers<T> = T where T: RandomAccessCollection, T.Element == Int

func doSomething<Source>(
  _ source: Source
) where IsRandomAccessCollectionOfIntegers<Source>: Any {
//                                                ^^^^^ - this is where the magic happens :)
  let _: Int? = source.first  // ✅
}

func useDoSomething() {
  doSomething([1, 2, 3])  // ✅
  doSomething(["one", "two", "three"])  // ❌ Cannot convert value of type 'String' to expected element type 'Int'
}

Basically, it allows you to write "constraint aliases" and simplify repeated, verbose generic constraints.

I suspect this is an implementation accident, and I wouldn't be surprised if it isn't tested either in the compiler's test suite or the source-compact suite, but it's awesome and I hope it doesn't get broken unless it is being replaced by true constraint aliases (which would be a good thing to add as part of the overall work to make generics more approachable, IMO).

xwu · 2022-01-06T15:38:32.680Z

This is completely inscrutable and super neat!

hborla · 2022-01-06T17:29:28.909Z

gwendal.roue:

And let's make sure, at the same time, that we support the technique described here , by not emitting any warning for any Foo even if Foo is an alias to Any

I agree:

hborla:

I thought about the use case for typealiasing Any a bit more and I think this example should be the same as other type aliases that can be used as generic constraints:
typealias Foo = Any

protocol P1: Foo { ... }
func bar(foo: any Foo)
Otherwise, when the type alias switches from Any to e.g. Sendable , the code would break (under a language mode where any is required).

Karl:

Basically, it allows you to write "constraint aliases" and simplify repeated, verbose generic constraints.

I suspect this is an implementation accident, and I wouldn't be surprised if it isn't tested either in the compiler's test suite or the source-compact suite, but it's awesome and I hope it doesn't get broken unless it is being replaced by true constraint aliases

This feature is called requirement inference. You could achieve the same thing using a same-type constraint IsRandomAccessCollectionOfIntegers<Source> == Source if you only want to write the type alias in the where clause (except the compiler currently warns that this same-type constraint is redundant even though it adds requirements via inference). In any case, I'm not proposing to remove the ability to write an unconstrained constraint. There would also be no replacement for some Any, which could be useful for some of the future directions around using opaque types in parameter position.

Douglas_Gregor · 2022-01-07T19:15:22.162Z

Hey all,

Thanks for the fantastic discussion. The Core Team has discussed this proposal and accepted it with modifications. The review result is here.

Doug

ebg · 2022-03-28T14:24:41.364Z

Which compiler flag will enable this warning in Swift 5.6?

davdroman · 2022-03-29T16:02:25.448Z

ebg:

Which compiler flag will enable this warning in Swift 5.6?

There are none (by design):

Finding existentials for `any` Using Swift

There isn't currently a way to turn on warnings for missing anys in your code. That's intentional; we're working on a lot of generics ergonomics features right now that may change the way programmers update their current use of existential types. A lot of Swift code today uses existential types where it doesn't need to because existential types were the more natural thing to write. With opaque parameters and existential opening for function arguments that's being worked on right now, a lot of c…