On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka <cocoa...@charlessoft.com>
wrote:

> On Aug 16, 2016, at 7:08 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>
> On Tue, Aug 16, 2016 at 6:59 PM, Karl <razie...@gmail.com> wrote:
>
>>
>> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>
>>
>> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> On Aug 16, 2016, at 5:13 PM, David Sweeris <daveswee...@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@swift.org
>> 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?


> Charles
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to