[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

Thu Jun 9 03:13:48 CDT 2016

> On Jun 9, 2016, at 8:06 AM, Austin Zheng <austinzheng at gmail.com> wrote:
> 
> According to that code (which is in Decl.cpp), AnyObject (and Any) conforms to itself; no non- at 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 <laurent.mihalkovic at gmail.com> wrote:
>> 
>> 
>> 
>> On Jun 8, 2016, at 9:43 PM, Austin Zheng via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org> wrote:
>>>> 
>>>> > Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution <swift-evolution at swift.org>:
>>>> >
>>>> >
>>>> > on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>>>> >
>>>> >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams <dabrahams at apple.com> 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 <swift-evolution at swift.org> wrote:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> on Tue Jun 07 2016, Matthew Johnson <swift-evolution at swift.org> 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
>>>> > swift-evolution at swift.org
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/fc517ed6/attachment.html>