When you call foo(_: A) with a concrete type C, the type checker
performs a conformance check of C to P. If C is a protocol type, the
conformance check fails. Ie, unlike the subtype relation (roughly, “I can
assign a value of this type to that”), the conformance relation (“I can
substitute this
> On 30 Dec 2016, at 17:26, Mikhail Seriukov wrote:
>
> So as the foo(_ x:A) function is generic, when we call foo(x) compiler
> needs to determine what type is A to be able to create concrete function. But
> x defined as let x = X() as P so we only know about it that it conforms to P
> but n
So as the *foo(_ x:A) *function is generic, when we call *foo(x) *compiler
needs to determine what type is *A *to be able to create concrete function.
But x defined as *let x = X() as P *so we only know about it that it
conforms to *P *but not its real type to put instead of *A*. Right?
But where i
> On 30 Dec 2016, at 12:14, Mikhail Seriukov via swift-users
> wrote:
>
> Ok,
> But I think I still do not get it.
> What does really happen when we write this?
>> let x = X() as P
>>
'X()' creates a value.
'as P’ constrains the value such that the only things we know about it is that
the v
Ok,
But I think I still do not get it.
What does really happen when we write this?
let x = X() as P
As I said, I expect x to be Any after that. If it is, then it should be
ok IMO.
But if it is not then what is the actual type of x?
So the real question is how the type checker works here?
2016-
> On Dec 22, 2016, at 4:43 PM, Howard Lovatt via swift-users
> wrote:
>
> The following variation works:
>
> protocol P {}
>
> class P1:P {}
>
> class X:P1 {}
>
> func foo(_ x:A) {}
>
> func bar() {
> //let x = X() // this compiles
> let x = X() as P1 // this does not compile. Why?
My previous theory was wrong.
> P is an existential for x: P = … where it is upgraded to the static P in foo
Why it needs to be upgraded? Why not just use `P` as a protocol instead of
a `type`? Xcode error message calls `P` as a type.
Zhaoxin
On Fri, Dec 23, 2016 at 9:03 PM, Adrian Zubarev <
a
I’m not sure what you mean. P is an existential for x: P = … where it is
upgraded to the static P in foo, but the static P does not conform to
the existential P, which results in an error described by the OP.
x: P = … here it’s Any any type that conforms to P. Any is a type of it’s
own, and whe
You mis-labelled you problem in your original email.
let x = X() as P // this does not compile. Why?
foo(x)
The issue is not in line ` let x = X() as P`. It is in line ` foo(x)`, `x's
type is P`, but `foo(:)` request a parameter type of `A`, not `P`.
`func foo(_ x:A) {}` means, `x` must
Whoops, wait a second. Correcting my self here. Copied the wrong url.
Here is the proposal I meant. LINK
--
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
I assume when we get existentials, your problem could be solved like this:
protocol P {}
class X: P {}
func foo(_ x:A) {}
func bar() {
let x = X() as Any
foo(x)
}
Here A will be Any which conforms to P and makes the compiler happy.
let c: P = … here is P and existential like (future) An
Sorry, should have taken the comments out of the example, they obviously have
no meaning anymore.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Swiftrien
Project: http://swiftfire.nl
> On 23 Dec 2016, at 10:03, Rien wrote:
>
>
>>
> On 23 Dec 2016, at 09:43, Mikhail Seriukov wrote:
>
> 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 wit
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)?!
AnyObject is for classes, but you’d get the same result changing X to a class ;)
If you want scratch the surface of what happ
>
> 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 s
on Thu Dec 22 2016, Mikhail Seriukov 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(_ x:A) {}
>
> func bar() {
> //let x = X() // this compiles
> let x = X() as P // this does no
The function foo(x: A){} requires a type which conforms to protocol P.
An existential of protocol P does not actually conform to protocol P.
It’s always been a limitation in Swift: https://bugs.swift.org/browse/SR-55
If the function’s signature were foo(x: P){}, it would work.
Howard’s example
The following variation works:
protocol P {}
class P1:P {}
class X:P1 {}
func foo(_ 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.
Note two changes: 1. two levels of inhe
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
I suspect a compiler bug since A is a P. The equivalent in Java works:
interface P {}
class X implements 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
> wrote:
>
> IMO the error message says it all
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
Hello community! I' wondering if somebody can explain this to me.
Please take look at the snippet.
protocol P {}
struct X:P {}
func foo(_ 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 thou
22 matches
Mail list logo
