> On Aug 16, 2016, at 6:05 PM, Charles Srstka via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Aug 16, 2016, at 7:48 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto: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 :.
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@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
