Re: [swift-users] Swift 3 Whole Module Optimization Issue

2016-12-23 Thread Jun Zhang via swift-users
This is the bug report: https://bugs.swift.org/browse/SR-3474

On Thu, Dec 22, 2016 at 11:08 AM, Jun Zhang 
wrote:

> Hi, everyone.
>I think I found a swift 3 whole module optimization issue. The code
> below, when building with release configuration and running on an iOS 10
> real device, will always causes a crash.
>
> import UIKit
>> class ViewController: UIViewController {
>> override func viewDidLoad() {
>> super.viewDidLoad()
>> // Do any additional setup after loading the view.
>> super.viewDidLoad()
>>
>> let orderby = "time"
>> let url = "http://www.sample.com/api/index.php?\(orderby)"
>>
>> Log("Request url: \(url)")
>>
>> if let url = URL(string: url) {
>> let request = URLRequest(url: url)
>> print(request)
>> }
>> }
>> override func didReceiveMemoryWarning() {
>> super.didReceiveMemoryWarning()
>> // Dispose of any resources that can be recreated.
>> }
>>
>> }
>> func Log(_ log: String) {
>> //NSLog("%@", log)
>> }
>
>
> You can see the attachment for more detail info.
> Or if you use github, this is the repo:
> https://github.com/zaczh/Swift3ClosureDemo​
>  Swift3ClosureDemo-master.zip
> 
> ​
>
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users


Re: [swift-users] Weird protocol behaviour.

2016-12-23 Thread Zhao Xin via swift-users
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 <
adrian.zuba...@devandartist.com> wrote:

> 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 when existentials will be implemented I’d assume that
> there won’t be any upgrade to P from generic context.
>
> let x: Any = …
>
> foo(x)
> // A == Any which should make foo equivalent to
> // `func foo(_ x: Any)` or the current `func foo(_ x: P)`
>
> Right now we just cannot be explicit about existentials.
>
> Please correct me if I’m wrong. ;)
>
>
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 23. Dezember 2016 um 13:47:18, Zhao Xin (owe...@gmail.com) schrieb:
>
> 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 be `A`, and `A` conforms `P`.
> But not all `P`s are `A`.
>
> Zhaoxin
>
> On Fri, Dec 23, 2016 at 5:26 PM, Adrian Zubarev via swift-users <
> swift-users@swift.org> wrote:
>
>> 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 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 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 :
>>
>>>
>>> On 22 Dec 2016, at 22:43, Howard Lovatt  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?
>>> 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 
>>> 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 

Re: [swift-users] Weird protocol behaviour.

2016-12-23 Thread Adrian Zubarev via swift-users
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 when existentials will be implemented I’d assume that there won’t be 
any upgrade to P from generic context.

let x: Any = …

foo(x)  
// A == Any which should make foo equivalent to  
// `func foo(_ x: Any)` or the current `func foo(_ x: P)`
Right now we just cannot be explicit about existentials.

Please correct me if I’m wrong. ;)



-- 
Adrian Zubarev
Sent with Airmail

Am 23. Dezember 2016 um 13:47:18, Zhao Xin (owe...@gmail.com) schrieb:

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 be `A`, and `A` conforms `P`. But not 
all `P`s are `A`.

Zhaoxin

On Fri, Dec 23, 2016 at 5:26 PM, Adrian Zubarev via swift-users 
 wrote:
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 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 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 :

On 22 Dec 2016, at 22:43, Howard Lovatt  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?
    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  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 
 wrote:

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:

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 
 wrote:

Hello community! I' 

Re: [swift-users] Possible bug in Swift REPL autocompletion?

2016-12-23 Thread Alex Blewitt via swift-users
I think this is a known issue but I don't know what the bug is. Please can you 
create a bug on https://bugs.swift.org  and include a 
reproduction, including what output you see?

Thanks,

Alex

> On 22 Dec 2016, at 21:19, Eugenio Baglieri via swift-users 
>  wrote:
> 
> Good evening, i was  playing with swift REPL. I imported Darwin and using c 
> functions. I noted that autocompletion is unusable if the last character is a 
> parenthesis “(“. 
> The autocompletion seems to not get account of the already written function 
> name, and after parenthesis shows as possible completion an infinite list 
> with all the parameters of all loaded libraries. 
> 
> Is this an issue that could be opened? You can reproduce this following these 
> steps:
> 
> - launch swift from terminal
> - write “import Darwin” on Mac, or “import Glibc” on Ubuntu
> - digit “fop” and press tab, you’ll get autocompleted with “fopen(“ press tab 
> again
> 
> — 
> Eugenio B.
> 
> 
> ___
> 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


Re: [swift-users] Swift 3 Whole Module Optimization Issue

2016-12-23 Thread Alex Blewitt via swift-users
Can you raise a bug at https://bugs.swift.org  with 
the details, including the crash dump?

Thanks,

Alex

> On 22 Dec 2016, at 02:48, Jun Zhang via swift-users  
> wrote:
> 
> Hi, everyone.
>I think I found a swift 3 whole module optimization issue. The code below, 
> when building with release configuration and running on an iOS 10 real 
> device, will always causes a crash.
> 
> import UIKit
> class ViewController: UIViewController {
> override func viewDidLoad() {
> super.viewDidLoad()
> // Do any additional setup after loading the view.
> super.viewDidLoad()
> 
> let orderby = "time"
> let url = "http://www.sample.com/api/index.php 
> ?\(orderby)"
> 
> Log("Request url: \(url)")
> 
> if let url = URL(string: url) {
> let request = URLRequest(url: url)
> print(request)
> }
> }
> override func didReceiveMemoryWarning() {
> super.didReceiveMemoryWarning()
> // Dispose of any resources that can be recreated.
> }
> 
> }
> func Log(_ log: String) {
> //NSLog("%@", log)
> }
> 
> You can see the attachment for more detail info.
> Or if you use github, this is the repo: 
> https://github.com/zaczh/Swift3ClosureDemo 
> 
> ​
>  Swift3ClosureDemo-master.zip 
> ​
> ___
> 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


Re: [swift-users] Weird protocol behaviour.

2016-12-23 Thread Adrian Zubarev via swift-users
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) Any.
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)?!

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 :

On 22 Dec 2016, at 22:43, Howard Lovatt  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?
    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  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 
 wrote:

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:

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 
 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 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

Re: [swift-users] Weird protocol behaviour.

2016-12-23 Thread Rien via swift-users

> 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 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?

Yes, but only for a destination that needs a protocol. Not for a destination 
that needs a type.

I.e. in the example

protocol P {}
struct X:P {}

func foo(_ x:A) {}

func bar(_ x:P) {}

func bar() {
var p: P
//let x = X() // this compiles
let x = X() as P // this does not compile. Why?
p = x
bar(p)
}

Regards,
Rien.

> 
> 2016-12-23 14:51 GMT+07:00 Marinus van der Lugt :
> 
>> On 22 Dec 2016, at 22:43, Howard Lovatt  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?
>> 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  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 
>>>  wrote:
>>> 
>>> 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:
 
 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 
>  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 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

Re: [swift-users] Weird protocol behaviour.

2016-12-23 Thread Adrian Zubarev via swift-users
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 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 :

On 22 Dec 2016, at 22:43, Howard Lovatt  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?
    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  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 
 wrote:

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:

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 
 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 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


Re: [swift-users] Weird protocol behaviour.

2016-12-23 Thread Mikhail Seriukov via swift-users
>
> 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 :

>
> On 22 Dec 2016, at 22:43, Howard Lovatt  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?
> 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  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 {}
>>
>>  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:
>>
>> 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(_ 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