Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I would like to add something to this discussion on casting generics. I think there is a temptation to think of generic types as having a protocol-like aspect. If String conforms to Any, then a [String] ought to conform to [Any]; the current scope may think of the variable as being a [Any] even th

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On Aug 8, 2017, at 06:38, Karl Wagner wrote: > > >>> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution >>> wrote: >>> >>> >>> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution >>> wrote: >>> >>> One of my longstanding frustrations with generic types and protocols ha

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On 8. Aug 2017, at 04:35, David Sweeris via swift-evolution > wrote: > >> >> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> One of my longstanding frustrations with generic types and protocols has >> been how hard it is to wo

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I see what you're saying, and I agree that this is more of a half-measure. But the benefit of this approach is that it's pretty trivial to implement, and the language features it introduces could be reimplemented with existentialists when they become available. I think advancing the syntax of the l

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

To my understanding, the following is exactly as it should be: FooStruct as? FooStruct // Compiles but conversion fails, becomes nil, and that's normal The reason for this is that FooStruct is not a subtype of FooStruct (or just FooStruct), while String is of course a subtype of Any, because g

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

Thanks for the feedback! Félix, sorry about the confusion between FooStruct and FooProtocol - I'll refer to them as such moving forwards. David, I don't believe you should be able to cast an [FooStruct] to an [FooStruct] because those are both valid specifications. If Generalized Existentials

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

Covariant generic types make for an unsound type system. I believe the reason why Array and Optional are covariant in their generic parameter is that the way their implementation interacts with their internal storage assures that new storage is created if types mismatch: this means that to make

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

I'm going to separate your examples into FooStruct and FooProtocol for clarity. I agree that generics tend to propagate virally and I remember that at some point I wanted type erasure, though I don't remember for what exactly. The solution for `sayHi`, right now, is to make that one generic too:

Re: [swift-evolution] [Pitch] Improving unspecified generic usability

> On Aug 7, 2017, at 3:00 PM, Logan Shire via swift-evolution > wrote: > > One of my longstanding frustrations with generic types and protocols has been > how hard it is to work with them when their type is unspecified. > Often I find myself wishing that I could write a function that takes a

[swift-evolution] [Pitch] Improving unspecified generic usability

One of my longstanding frustrations with generic types and protocols has been how hard it is to work with them when their type is unspecified. Often I find myself wishing that I could write a function that takes a generic type or protocol as a parameter, but doesn’t care what its generic type is.