I assume when we get existentials, your problem could be solved like this:
protocol P {}
class X: P {}
func foo<A:P>(_ x:A) {}
func bar() {
let x = X() as Any<P>
foo(x)
}
Here A will be Any<P> which conforms to P and makes the compiler happy.
let c: P = … here is P and existential like (future) Any<P>.
x as P here is P used as a type.
It’s weird that the latter is a type but the first example is an existential. I
think this is a design choice, because we almost never need the protocol as a
type.
--
Adrian Zubarev
Sent with Airmail
Am 23. Dezember 2016 um 09:57:49, Adrian Zubarev
(adrian.zuba...@devandartist.com) schrieb:
What are you trying to solve here?
Do you heavily rely on what A can be?
Can’t you just write func foo(_ x: P) {} (here P is an existential like [in
some future] Any<P>)?!
AnyObject is for classes, but you’d get the same result changing X to a class ;)
If you want scratch the surface of what happens to protocols in a generic
context, you could read our proposal about meta types here.
--
Adrian Zubarev
Sent with Airmail
Am 23. Dezember 2016 um 09:43:34, Mikhail Seriukov via swift-users
(swift-users@swift.org) schrieb:
No it does not.
You have made a type out of the parameter. It’s no longer a protocol.
IMO the failure here is to understand the difference between a type and a
protocol.
A type (even if empty) is always a combination of storage with functions (that
are assumed to work on the data in storage)
A protocol is just a definition of functions without the accompanying data.
I see your point.
But actually when I write it as `let x = X() as P` I really mean that I want
`x` to be `AnyObject` but conforming to P, not just protocol itself.
Is it even possible to downcast it this way?
2016-12-23 14:51 GMT+07:00 Marinus van der Lugt <r...@starbase55.com>:
On 22 Dec 2016, at 22:43, Howard Lovatt <howard.lov...@gmail.com> wrote:
The following variation works:
protocol P {}
class P1:P {}
class X:P1 {}
func foo<A:P>(_ x:A) {}
func bar() {
//let x = X() // this compiles
let x = X() as P1 // this does not compile. Why?
foo(x)
}
Which adds credence to the bug theory.
No it does not.
You have made a type out of the parameter. It’s no longer a protocol.
IMO the failure here is to understand the difference between a type and a
protocol.
A type (even if empty) is always a combination of storage with functions (that
are assumed to work on the data in storage)
A protocol is just a definition of functions without the accompanying data.
Rien.
Note two changes: 1. two levels of inheritance and 2. change to classes. If you
do two levels using protocols it doesn't work if you use either classes or
structs.
-- Howard.
On 23 December 2016 at 07:29, Kevin Nattinger <sw...@nattinger.net> wrote:
I recall seeing a request on the -evolution list for something like `T := X` to
indicate it could be X itself or anything inheriting / implementing it, so it’s
certainly known behavior, if not desired. IMO it’s a bug and `:` should be
fixed to include the root type, whether or not that requires a discussion on
-evolution.
On Dec 22, 2016, at 2:17 PM, Howard Lovatt via swift-users
<swift-users@swift.org> wrote:
I suspect a compiler bug since A is a P. The equivalent in Java works:
interface P {}
class X implements P {}
<A extends P> void foo(A x) {}
void bar() {
final P x = new X();
foo(x);
}
-- Howard.
On 23 Dec 2016, at 3:19 am, Rien via swift-users <swift-users@swift.org> wrote:
IMO the error message says it all:
Playground execution failed: error: MyPlayground8.playground:9:5: error: cannot
invoke 'foo' with an argument list of type '(P)'
foo(x)
^
MyPlayground8.playground:9:5: note: expected an argument list of type '(A)'
foo(x)
^
I.e. you are passing in a protocol while the function is specified for a type.
Said other way: On which data do you expect the protocol to operate?
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
On 22 Dec 2016, at 17:05, Mikhail Seriukov via swift-users
<swift-users@swift.org> wrote:
Hello community! I' wondering if somebody can explain this to me.
Please take look at the snippet.
protocol P {}
struct X:P {}
func foo<A:P>(_ x:A) {}
func bar() {
//let x = X() // this compiles
let x = X() as P // this does not compile. Why?
foo(x)
}
I expect the both cases to work though. But only first works? And I do not
understand why.
My coworkers said that it is a compiler bug, but I'm not shure it is.
Thanks for the help.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users
