> On Jan 4, 2016, at 10:30 AM, Matthew Johnson <[email protected]> wrote:
>
>>
>> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Jan 3, 2016, at 4:19 PM, David Waite <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> This would be wonderful - is it something that could happen in the Swift 3
>>> timeframe?
>>
>> I hesitate to say “yes” here. I think it fits with the goals of Swift 3, but
>> my main concern is that there isn’t enough engineering bandwidth to
>> implement it for Swift 3.
>>
>>> Is it something that myself or someone else could work on a formal proposal
>>> for?
>>
>> Yes, absolutely. This is a case where I think it’s useful to design what we
>> want, even if we cannot fit the implementation into the Swift 3 schedule.
>> It’s also a case where the compiler has a lot of the pieces already
>> implemented (with some runtime bits landing soon), so the implementation
>> should not be *that* hard and will likely not require architectural changes.
>
> Interesting. I was under the impression the core team was taking on the
> generics features.
We are, and lots of them. I doubt we can handle another.
> I am also very interested in helping to accelerate the process if that is
> possible (whether that means Swift 3 or not).
>
> Are you thinking specifically about unbound existentials like in your
> Equatable example or also partly / fully bound existentials such as
> SequenceType<Generator.Element == Int>?
I was thinking mostly about the former. However, the latter is also a
highly-requested feature [*] that complements this one, and I think it’s
reasonable to discuss both together.
- Doug
[*] And is often the underlying reason why developers ask for parameterized
protocols.
>
>>
>> - Doug
>>
>>>
>>> -DW
>>>
>>>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>
>>>>
>>>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution
>>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>>
>>>>> Introduction of interfaces will clean up the current blend of static and
>>>>> dynamic protocols, and solve at least three popular issues.
>>>>> Please see:
>>>>> https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md
>>>>>
>>>>> <https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md>
>>>> I am *completely* against this proposal.
>>>>
>>>> Fundamentally, you're trying to address the limitation that protocols with
>>>> Self or associated type requirements can't be existential. But it's just a
>>>> limitation that isn't (conceptually) that hard to fix: the primary
>>>> operation you need to work with an existing of such a protocol is to
>>>> "open" a value of existential type, giving a name to the dynamic type it
>>>> stores. Let's invent one:
>>>>
>>>> func eq(x: Equatable, y: Equatable) -> Bool {
>>>> // give the name T to the dynamic type stored in xT
>>>> let xT = open x as T
>>>> // is y also storing a T?
>>>> guard let yT = y as? T else { return false }
>>>> // check whether the Ts are equal
>>>> return xT == yT
>>>> }
>>>>
>>>> Ignore the syntax: semantically, we've gone from a "dynamic" existential
>>>> thing back to something more "static", just by giving a name to the type.
>>>> Swift generics aren't really even static in any sense: what the do is give
>>>> names to the types of values so one can establish relationships among
>>>> different values. "open..as" would do that for existentials.
>>>>
>>>> Note that ether Swift compilers AST and SIL both have "open existential"
>>>> operations that do this internally. They have no spelling in Swift code,
>>>> but they are useful to describe operations on existentials. At present,
>>>> they cannot be formed when the existential involves a protocol with Self
>>>> or associated type requirements, but that's a limitation that isn't hard
>>>> to address.
>>>>
>>>> As for your concerns about knowing when one can dynamically override and
>>>> when one cannot... There are issues here that need to be addressed. They
>>>> aren't significant enough to warrant such a drastic change, and may not
>>>> even require language changes at all.
>>>>
>>>> - Doug
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> [email protected] <mailto:[email protected]>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
