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
> 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
> 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
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
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
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
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 too:
> 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
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.
10 matches
Mail list logo