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
