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
> 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:
>>>
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
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
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
> 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