> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Aug 16, 2016 at 7:43 PM, Charles Srstka <cocoa...@charlessoft.com > <mailto:cocoa...@charlessoft.com>> wrote: >> On Aug 16, 2016, at 7:08 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Tue, Aug 16, 2016 at 6:59 PM, Karl <razie...@gmail.com >> <mailto:razie...@gmail.com>> wrote: >> >>> On 17 Aug 2016, at 00:34, Charles Srstka via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>>> On Aug 16, 2016, at 5:30 PM, Xiaodi Wu <xiaodi...@gmail.com >>>> <mailto:xiaodi...@gmail.com>> wrote: >>>> >>>> On Tue, Aug 16, 2016 at 5:19 PM, Charles Srstka via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> On Aug 16, 2016, at 5:13 PM, David Sweeris <daveswee...@mac.com >>>>> <mailto: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 <mailto:swift-evolution@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 :. Charles
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution