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

[Austin Zheng]

Yes, you were correct. Thanks for spotting that and apologies for not
acknowledging you sooner.

Austin

On Thu, Jun 9, 2016 at 1:13 AM, L. Mihalkovic <laurent.mihalkovic at gmail.com>
wrote:

>
> 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
>> <http://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/> <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/a4fdf153/attachment-0001.html>