> On Jun 9, 2016, at 8:06 AM, Austin Zheng <[email protected]> wrote: > > According to that code (which is in Decl.cpp), AnyObject (and Any) conforms > to itself; no non-@objc protocol is allowed to conform to itself. An @objc > protocol may or may not conform to itself, depending on some other conditions.
Like I said... more sub-cases than your original statement, right?! > >> On Jun 8, 2016, at 9:19 PM, L. Mihalkovic <[email protected]> >> wrote: >> >> >> >> On Jun 8, 2016, at 9:43 PM, Austin Zheng via swift-evolution >> <[email protected]> wrote: >> >>> It's not possible, even with Swift's current implementation of >>> existentials. A protocol type P isn't considered to conform to itself, thus >>> the following is rejected: >> >> The rules are not that simple, I seem to recall reading in sourcecode that >> there are criteria that decide if that is true or not. And by default the >> variable conform_to_self is even TRUE >> >> >>> >>> let a : MyProtocol = // ... >>> func myFunc<T : MyProtocol>(x: T) { >>> // .... >>> } >>> myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type >>> MyProtocol" >>> >>> Changing how this works is probably worth a proposal by itself. >>> >>> Austin >>> >>> >>>> On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> > Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution >>>> > <[email protected]>: >>>> > >>>> > >>>> > on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote: >>>> > >>>> >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams <[email protected]> wrote: >>>> >>> >>>> >>> >>>> >>> on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com >>>> >>> <http://matthew-at-anandabits.com/>> wrote: >>>> >>> >>>> >> >>>> >>>>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution >>>> >>>>> <[email protected]> wrote: >>>> >>>>> >>>> >>>>> >>>> >>>>> on Tue Jun 07 2016, Matthew Johnson <[email protected]> >>>> >>>>> wrote: >>>> >>>>> >>>> >>>> >>>> >>>>>>> , but haven't realized >>>> >>>>>>> that if you step around the type relationships encoded in Self >>>> >>>>>>> requirements and associated types you end up with types that >>>> >>>>>>> appear to >>>> >>>>>>> interoperate but in fact trap at runtime unless used in exactly the >>>> >>>>>>> right way. >>>> >>>>>> >>>> >>>>>> Trap at runtime? How so? Generalized existentials should still be >>>> >>>>>> type-safe. >>>> >>>>> >>>> >>>>> There are two choices when you erase static type relationships: >>>> >>>>> >>>> >>>>> 1. Acheive type-safety by trapping at runtime >>>> >>>>> >>>> >>>>> FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap >>>> >>>>> >>>> >>>>> 2. Don't expose protocol requirements that involve these >>>> >>>>> relationships, >>>> >>>>> which would prevent the code above from compiling and prevent >>>> >>>>> FloatingPoint from conforming to itself. >>>> >>>>> >>>> >>>>>> Or are you talking about the hypothetical types / behaviors people >>>> >>>>>> think they want when they don’t fully understand what is >>>> >>>>>> happening... >>>> >>>>> >>>> >>>>> I don't know what you mean here. I think generalized existentials >>>> >>>>> will >>>> >>>>> be nice to have, but I think most people will want them to do >>>> >>>>> something >>>> >>>>> they can't possibly do. >>>> >>>> >>>> >>>> Exactly. What I meant is that people think they want that expression >>>> >>>> to compile because they don’t understand that the only thing it can do >>>> >>>> is trap. I said “hypothetical” because producing a compile time error >>>> >>>> rather than a runtime trap is the only sane thing to do. Your comment >>>> >>>> surprised me because I can’t imagine we would move forward in Swift >>>> >>>> with the approach of trapping. >>>> >>> >>>> >>> I would very much like to be able to create instances of “Collection >>>> >>> where Element == Int” so we can throw away the wrappers in the stdlib. >>>> >>> That will require some type mismatches to be caught at runtime via >>>> >>> trapping. >>>> >> >>>> >> For invalid index because the existential accepts a type erased index? >>>> > >>>> > Exactly. >>>> > >>>> >> How do you decide where to draw the line here? It feels like a very >>>> >> slippery slope for a language where safety is a stated priority to >>>> >> start adopting a strategy of runtime trapping for something as >>>> >> fundamental as how you expose members on an existential. >>>> > >>>> > If you don't do this, the alternative is that “Collection where Element >>>> > == Int” does not conform to Collection. That's weird and not very >>>> > useful. You could expose all the methods that were on protocol >>>> > extensions of Collection on this existential, unless they used >>>> > associated types other than the element type. But you couldn't pass the >>>> > existential to a generic function like >>>> > >>>> > func scrambled<C: Collection>(_ c: C) -> [C.Element] >>>> >>>> I don’t understand. Why couldn’t an existential be passed to that function? >>>> >>>> -Thorsten >>>> >>>> >>>> >>>> > >>>> >> IMO you should *have* to introduce unsafe behavior like that manually. >>>> > >>>> > Collection where Element == Int & Index == * >>>> > >>>> > ? >>>> > >>>> >> Collection indices are already something that isn’t fully statically >>>> >> safe so I understand why you might want to allow this. >>>> > >>>> > By the same measure, so are Ints :-) >>>> > >>>> > The fact that a type's methods have preconditions does *not* make it >>>> > “statically unsafe.” >>>> > >>>> >> But I don’t think having the language's existentials do this >>>> >> automatically is the right approach. Maybe there is another approach >>>> >> that could be used in targeted use cases where the less safe behavior >>>> >> makes sense and is carefully designed. >>>> > >>>> > Whether it makes sense or not really depends on the use-cases. There's >>>> > little point in generalizing existentials if the result isn't very >>>> > useful. >>>> > The way to find out is to take a look at the examples we currently have >>>> > of protocols with associated types or Self requirements and consider >>>> > what you'd be able to do with their existentials if type relationships >>>> > couldn't be erased. >>>> > >>>> > We have known use-cases, currently emulated in the standard library, for >>>> > existentials with erased type relationships. *If* these represent the >>>> > predominant use cases for something like generalized existentials, it >>>> > seems to me that the language feature should support that. Note: I have >>>> > not seen anyone build an emulation of the other kind of generalized >>>> > existential. My theory: there's a good reason for that :-). >>>> > >>>> > -- >>>> > Dave >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > [email protected] >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
