[swift-evolution] PITCH: New :== operator for generic constraints

Tue Aug 16 20:14:07 CDT 2016

> On Aug 16, 2016, at 6:05 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>> 
>> On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka <cocoadev at charlessoft.com <mailto:cocoadev at charlessoft.com>> wrote:
>>> On Aug 16, 2016, at 7:08 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>>> 
>>> On Tue, Aug 16, 2016 at 6:59 PM, Karl <razielim at gmail.com <mailto:razielim at gmail.com>> wrote:
>>> 
>>>> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>>> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>>>>> 
>>>>> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>> On Aug 16, 2016, at 5:13 PM, David Sweeris <davesweeris at mac.com <mailto:davesweeris at mac.com>> 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
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> 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 :.

I don’t think it’s reasonable to specify language features as requiring a pre-processor for implementation. It would break a lot of things in the language design, and mental model.

> 
> Charles
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160816/8398dee1/attachment.html>