> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu <[email protected]> wrote:
>
> On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka <[email protected]
> <mailto:[email protected]>> wrote:
>> On Aug 16, 2016, at 7:08 PM, Xiaodi Wu <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> On Tue, Aug 16, 2016 at 6:59 PM, Karl <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution
>>> <[email protected] <mailto:[email protected]>> wrote:
>>>
>>>> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu <[email protected]
>>>> <mailto:[email protected]>> wrote:
>>>>
>>>> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution
>>>> <[email protected] <mailto:[email protected]>> wrote:
>>>>> On Aug 16, 2016, at 5:13 PM, David Sweeris <[email protected]
>>>>> <mailto:[email protected]>> wrote:
>>>>>
>>>>> Any proposal that expands the power of generic programming gets an almost
>>>>> automatic +1 from me.
>>>>>
>>>>> I can't think of any circumstances in which I wouldn't want to use ":=="
>>>>> instead of ":". Are there any downsides to expanding ":" to mean what
>>>>> ":==" does?
>>>>>
>>>>> Incidentally, I kinda thought things either already worked like this, or
>>>>> would work like this after generics were "completed", but I can't tell
>>>>> you why I thought that.
>>>>
>>>> Me neither, but the last time I proposed that, people stated that there
>>>> were some cases where this could not work. No concrete examples were
>>>> given, but I assume it probably has something to do with associated type
>>>> wackiness. :== seems like a workable compromise to me.
>>>>
>>>> If an existential of a protocol P doesn't conform to itself, what can you
>>>> do inside the body of a generic function that has a generic constraint
>>>> specified with `:==`? In other words, what would we know about what's in
>>>> common between such an existential of a protocol and types that conform to
>>>> the protocol?
>>>
>>> My proposal is that in such cases, using :== would lead to a compiler error.
>>>
>>> Charles
>>>
>>> _______________________________________________
>>> 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>
>> I think the point is that existentials not conforming to their protocols is
>> the underlying reason this doesn’t work already.
>>
>> From the previous thread:
>>> There are a couple of reasons this is the case. IIRC in some cases it
>>> actually isn't possible for the existential to conform to the protocol in a
>>> sound way. And even when it is possible, I believe it has been said that
>>> it is more difficult to implement than you might think. Hopefully the
>>> situation will improve in the future but I'm not aware of any specific
>>> plans at the moment.
>>
>> It seems like a reasonably straightforward axiom. I would be interested to
>> learn more about those edge-cases.
>>
>> Hmm, re-reading that makes me worry about this proposal at a practical
>> level. IIUC, this is something that is pretty much desired across the board,
>> and if we could have it for `:` it'd be best.
>> But, it sounds like the reason `:` doesn't work that way isn't that the core
>> team has a different opinion, but rather that it's very difficult to
>> implement. And, IIUC, the situation is that no protocol existential
>> currently conforms to itself, not that some do and some don't. The
>> implementation work wouldn't be any easier if we called the operator `:==`...
>
>
> There are various ways to work around the problem using a new operator,
> though, depending on how much work you wanted to do in implementing it. At
> the very least you could take the ‘preprocessor’ approach and turn one
> function using :== into two separate functions, one using == and one using :,
> with both functions sharing the same body. This would still have the code
> bloat in the binary, but at least it wouldn’t be bloating up the source. We
> could then solve some of the binary bloat by spinning off the function body
> into a third function and having both the two original functions call that.
> Or maybe we could have the : variant reinterpret the sequence as an ==
> sequence and send it to the == variant. There are multiple ways that this
> could be handled without forcing protocols to conform to themselves.
>
> Not an expert, but wouldn't this blow up a whole bunch of compile-time
> "stuff" like the type checker? If no protocol existential conforms to itself,
> and it's unknown to the compiler whether it's even theoretically possible for
> a particular protocol, then what's to say what the body of a function that
> uses this constraint should be able to do?
What happens if you try to do that by hand?
func foo<Foo: Sequence>(bar: Foo) where Foo.Iterator.Element == MyProto {
for eachFoo in bar {
eachFoo.baz()
}
}
func foo<Foo: Sequence>(bar: Foo) where Foo.Iterator.Element: MyProto {
for eachFoo in bar {
eachFoo.baz()
}
}
Answer: If either Element == MyProto or Element: MyProto can’t handle the baz()
method, it’ll throw a compiler error.
Generating the above code via a preprocessor would get the same result. :==
would only compile if the body worked with both == and with :.
Charles
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
