Discussion has stopped on this topic. Should I submit a proposal? > On Apr 18, 2016, at 1:55 PM, Ross O'Brien <[email protected]> wrote: > > Thanks Gwendal, that makes sense - for the case where Shape is a protocol. > > Since the OP wasn't clear about it, I tried the original example with both > the cases where Shape was declared as a protocol (i.e. Circle conforms) and > where Shape was declared as a class (i.e. Circle inherits). The same problem > occurs when Shape is a concrete type. Does the same explanation apply? i.e. > the 'MyShapeProtocol' trampoline has the same problem you've described? > > Yogev: this is the first stage - discussion on the list. The formal next > stage, assuming that there's some list support and the idea isn't on the list > of 'commonly rejected ideas' (I've been burned by this) is to write a > proposal using the draft proposal document in the Swift Evolution github > repository, and make a pull request. In due course proposals will be > scheduled for review. If a pull request for an implementation of an > acceptable proposal exists, the review may happen that much faster. > > On Mon, Apr 18, 2016 at 11:43 AM, Gwendal Roué <[email protected] > <mailto:[email protected]>> wrote: > Those "trampolines" are visible in debugger stack traces, or in Instruments, > as "protocol witness" function calls. You may have seen them already. > > You see, a variable of type SomeProtocol, or the result of a method that > returns a protocol, does not contain a value of any concrete type that adopts > the protocol. > > Instead, it contains a description of what should happen when a protocol > method is called. It's an indirection. An indirection that happens at > runtime. The compiler says: "I have to store a value of type T in a variable > declared as protocol P. I'll actually store the fact that when the function > f() of the protocol is called, it will actually call the function f() of the > type T." And those redirections are visible as "protocol witness" in our > stack traces. > > This allows a function that uses a Swift protocols to be used with types that > are not known yet by the compiler, such as the types defined by the user that > use a framework. Compile once, and run later, through the indirection. > > This also explains why it's not trivial to implement Yogev's request: a value > of type Circle (concrete type) has not the same memory layout than a value of > type Shape (a protocol trampoline). The same for functions that involve those > types. Some conversion has to happen, and this conversion must happen at > runtime, as we've seen above. Such support is not implemented (yet ?). > > I hope I was clear :-) > Gwendal > > >> Le 18 avr. 2016 à 12:19, Ross O'Brien <[email protected] >> <mailto:[email protected]>> a écrit : >> >> You may have to explain that metaphor (or link to an explanation) - what is >> 'trampoline' data? >> >> On Mon, Apr 18, 2016 at 11:11 AM, Gwendal Roué <[email protected] >> <mailto:[email protected]>> wrote: >> >> > Le 18 avr. 2016 à 12:01, Yogev Sitton <[email protected] >> > <mailto:[email protected]>> a écrit : >> > >> > I’m referring you to Ross O’Brien’s post: >> > As of Swift 2.2, if a variable has a closure type of e.g. () -> Shape, a >> > closure of type () -> Circle would be considered a match. If a class >> > implements 'func make() -> Shape', a subclass implementing 'func make() -> >> > Circle' has to override. However, if a protocol requires a 'func make() -> >> > Shape', a type implementing 'func make() -> Circle' isn't considered to be >> > conforming. That does seem strange. >> > >> > Protocols behaves differently than closures and classes and I think they >> > should behave the same. >> >> All right, I get it. >> >> Shape, as a return type, is "trampoline" data that wraps any Shape value, >> when Circle is just a Circle. That's why the two functions () -> Shape? and >> () -> Circle? don't match today. >> >> But maybe they will eventually, thanks to your request! >> >> Gwendal >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
