Re: [swift-users] Question with calling a method which returns `Self` on super

[吴君恺 via swift-users]

Thank you, Slava.

I will use the trick you provided.
And knowing that this bug has already been under tracking is a great comfort to 
me, really :)

Lincoln

> 在 2017年8月11日，上午11:29，Slava Pestov  写道：
> 
> 
>> On Aug 10, 2017, at 8:23 PM, Slava Pestov via swift-users 
>> mailto:swift-users@swift.org>> wrote:
>> 
>> Hi Lincoln,
>> 
>> This is a known issue with ‘super’ method calls: 
>> https://bugs.swift.org/browse/SR-1736 
>> 
>> A workaround is to cast the result of the supermethod call to Self 
>> explicitly:
>> 
>> let copied = super.copy() as! Self
> 
> I’m sorry, but this is nonsense. We don’t allow ‘Self’ to refer to the 
> dynamic Self type yet.
> 
> You could do something like this I guess,
> 
> func cast(from: T, to: U.Type) -> U {
>   return from as! U
> }
> 
> let copied = cast(from: super.copy(), to: type(of: self))
> 
> Slava
> 
>> 
>> Slava
>> 
>>> On Aug 10, 2017, at 8:16 PM, 吴君恺 via swift-users >> > wrote:
>>> 
>>> Hi all,
>>> 
>>> here is the scenario, I want to implement a Copying protocol which can be 
>>> used homogeneously
>>> 
>>> protocol Copying {
>>> func copy() -> Self
>>> }
>>> 
>>> Because this protocol contains neither associated-type-requirements or 
>>> self-requirements(requiring a method returning Self is different), it can 
>>> surely be used homogeneously.
>>> 
>>> let objects: [Copying] = 
>>> for copyable in objects {
>>> .
>>> }
>>> 
>>> It will work if I make one of my base class conform to Copying
>>> 
>>> class Shape: Copying {
>>> var color: UIColor?
>>> 
>>> required init() {}
>>> 
>>> func copy() -> Self {
>>> let copied = type(of: self).init()
>>> copied.color = color
>>> return copied
>>> }
>>> }
>>> 
>>> The implementation of `copy` above is forced by compiler to avoid any 
>>> explicit specification of type `Shape`, so that the returning value will 
>>> have a dynamic type, which is just what I want. Here, the type of `copied` 
>>> is `Self`
>>> 
>>> However, if I try to make a subclass of Shape, I can't find a elegant way 
>>> to implement this `copy` method in that subclass, the following code will 
>>> not compile.
>>> 
>>> class Circle: Shape {
>>> var radius: Float = 5
>>> 
>>> func copy() -> Self {
>>> let copied = super.copy() 
>>> copied.radius = radius // compilation error
>>> return copied
>>> }
>>> }
>>> 
>>> The compiler will complain that `copied` has no property `radius`. It turns 
>>> out that calling copy() on super will yield a value of type Shape, rather 
>>> than Self. 
>>> 
>>> Swift now forbids explicit conversion to `Self` (I totally agree with this 
>>> rule), and will automatically allow `Self` to be treated as a specific type 
>>> in some circumstances. But for this case, I wonder whether this is the 
>>> correct behavior or a bug? Why calling `super.copy()` not be able to get a 
>>> `Self`?
>>> 
>>> I did find a work-around for this problem afterwards, but this question 
>>> really haunts me...
>>> 
>>> Cheers,
>>> Lincoln.
>>> ___
>>> 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] Why no new Development Snapshots since Aug 3?

[Mishal Shah via swift-users]

Hi Jens, 

We are working on resolving LLDB build and test failures, once these failures  
have been resolved we will be releasing new toolchains.

https://ci.swift.org/job/oss-lldb-incremental-osx/
https://ci.swift.org/job/oss-lldb-incremental-linux-ubuntu-16_04/
https://ci.swift.org/job/oss-lldb-incremental-linux-ubuntu-16_10/

Thanks,
Mishal Shah

> On Aug 10, 2017, at 6:42 PM, Jens Persson via swift-users 
>  wrote:
> 
> The most recent Development Snapshot is 2017-08-03, but it used to be a new 
> one almost daily. What happened?
> /Jens
> ___
> 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] Question with calling a method which returns `Self` on super

[Slava Pestov via swift-users]

> On Aug 10, 2017, at 8:23 PM, Slava Pestov via swift-users 
>  wrote:
> 
> Hi Lincoln,
> 
> This is a known issue with ‘super’ method calls: 
> https://bugs.swift.org/browse/SR-1736 
> 
> A workaround is to cast the result of the supermethod call to Self explicitly:
> 
> let copied = super.copy() as! Self

I’m sorry, but this is nonsense. We don’t allow ‘Self’ to refer to the dynamic 
Self type yet.

You could do something like this I guess,

func cast(from: T, to: U.Type) -> U {
  return from as! U
}

let copied = cast(from: super.copy(), to: type(of: self))

Slava

> 
> Slava
> 
>> On Aug 10, 2017, at 8:16 PM, 吴君恺 via swift-users > > wrote:
>> 
>> Hi all,
>> 
>> here is the scenario, I want to implement a Copying protocol which can be 
>> used homogeneously
>> 
>> protocol Copying {
>> func copy() -> Self
>> }
>> 
>> Because this protocol contains neither associated-type-requirements or 
>> self-requirements(requiring a method returning Self is different), it can 
>> surely be used homogeneously.
>> 
>> let objects: [Copying] = 
>> for copyable in objects {
>> .
>> }
>> 
>> It will work if I make one of my base class conform to Copying
>> 
>> class Shape: Copying {
>> var color: UIColor?
>> 
>> required init() {}
>> 
>> func copy() -> Self {
>> let copied = type(of: self).init()
>> copied.color = color
>> return copied
>> }
>> }
>> 
>> The implementation of `copy` above is forced by compiler to avoid any 
>> explicit specification of type `Shape`, so that the returning value will 
>> have a dynamic type, which is just what I want. Here, the type of `copied` 
>> is `Self`
>> 
>> However, if I try to make a subclass of Shape, I can't find a elegant way to 
>> implement this `copy` method in that subclass, the following code will not 
>> compile.
>> 
>> class Circle: Shape {
>> var radius: Float = 5
>> 
>> func copy() -> Self {
>> let copied = super.copy() 
>> copied.radius = radius // compilation error
>> return copied
>> }
>> }
>> 
>> The compiler will complain that `copied` has no property `radius`. It turns 
>> out that calling copy() on super will yield a value of type Shape, rather 
>> than Self. 
>> 
>> Swift now forbids explicit conversion to `Self` (I totally agree with this 
>> rule), and will automatically allow `Self` to be treated as a specific type 
>> in some circumstances. But for this case, I wonder whether this is the 
>> correct behavior or a bug? Why calling `super.copy()` not be able to get a 
>> `Self`?
>> 
>> I did find a work-around for this problem afterwards, but this question 
>> really haunts me...
>> 
>> Cheers,
>> Lincoln.
>> ___
>> 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] Question with calling a method which returns `Self` on super

[Slava Pestov via swift-users]

Hi Lincoln,

This is a known issue with ‘super’ method calls: 
https://bugs.swift.org/browse/SR-1736 

A workaround is to cast the result of the supermethod call to Self explicitly:

let copied = super.copy() as! Self

Slava

> On Aug 10, 2017, at 8:16 PM, 吴君恺 via swift-users  
> wrote:
> 
> Hi all,
> 
> here is the scenario, I want to implement a Copying protocol which can be 
> used homogeneously
> 
> protocol Copying {
> func copy() -> Self
> }
> 
> Because this protocol contains neither associated-type-requirements or 
> self-requirements(requiring a method returning Self is different), it can 
> surely be used homogeneously.
> 
> let objects: [Copying] = 
> for copyable in objects {
> .
> }
> 
> It will work if I make one of my base class conform to Copying
> 
> class Shape: Copying {
> var color: UIColor?
> 
> required init() {}
> 
> func copy() -> Self {
> let copied = type(of: self).init()
> copied.color = color
> return copied
> }
> }
> 
> The implementation of `copy` above is forced by compiler to avoid any 
> explicit specification of type `Shape`, so that the returning value will have 
> a dynamic type, which is just what I want. Here, the type of `copied` is 
> `Self`
> 
> However, if I try to make a subclass of Shape, I can't find a elegant way to 
> implement this `copy` method in that subclass, the following code will not 
> compile.
> 
> class Circle: Shape {
> var radius: Float = 5
> 
> func copy() -> Self {
> let copied = super.copy() 
> copied.radius = radius // compilation error
> return copied
> }
> }
> 
> The compiler will complain that `copied` has no property `radius`. It turns 
> out that calling copy() on super will yield a value of type Shape, rather 
> than Self. 
> 
> Swift now forbids explicit conversion to `Self` (I totally agree with this 
> rule), and will automatically allow `Self` to be treated as a specific type 
> in some circumstances. But for this case, I wonder whether this is the 
> correct behavior or a bug? Why calling `super.copy()` not be able to get a 
> `Self`?
> 
> I did find a work-around for this problem afterwards, but this question 
> really haunts me...
> 
> Cheers,
> Lincoln.
> ___
> 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] Question with calling a method which returns `Self` on super

[吴君恺 via swift-users]

Hi all,

here is the scenario, I want to implement a Copying protocol which can be used 
homogeneously

protocol Copying {
func copy() -> Self
}

Because this protocol contains neither associated-type-requirements or 
self-requirements(requiring a method returning Self is different), it can 
surely be used homogeneously.

let objects: [Copying] = 
for copyable in objects {
.
}

It will work if I make one of my base class conform to Copying

class Shape: Copying {
var color: UIColor?

required init() {}

func copy() -> Self {
let copied = type(of: self).init()
copied.color = color
return copied
}
}

The implementation of `copy` above is forced by compiler to avoid any explicit 
specification of type `Shape`, so that the returning value will have a dynamic 
type, which is just what I want. Here, the type of `copied` is `Self`

However, if I try to make a subclass of Shape, I can't find a elegant way to 
implement this `copy` method in that subclass, the following code will not 
compile.

class Circle: Shape {
var radius: Float = 5

func copy() -> Self {
let copied = super.copy() 
copied.radius = radius // compilation error
return copied
}
}

The compiler will complain that `copied` has no property `radius`. It turns out 
that calling copy() on super will yield a value of type Shape, rather than 
Self. 

Swift now forbids explicit conversion to `Self` (I totally agree with this 
rule), and will automatically allow `Self` to be treated as a specific type in 
some circumstances. But for this case, I wonder whether this is the correct 
behavior or a bug? Why calling `super.copy()` not be able to get a `Self`?

I did find a work-around for this problem afterwards, but this question really 
haunts me...

Cheers,
Lincoln.___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] Why no new Development Snapshots since Aug 3?

[Michael Gottesman via swift-users]

This is a question for Mishal (+CC).

> On Aug 10, 2017, at 6:42 PM, Jens Persson via swift-users 
>  wrote:
> 
> The most recent Development Snapshot is 2017-08-03, but it used to be a new 
> one almost daily. What happened?
> /Jens
> ___
> 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] Why no new Development Snapshots since Aug 3?

[Jens Persson via swift-users]

The most recent Development Snapshot is 2017-08-03, but it used to be a new
one almost daily. What happened?
/Jens
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] #selector() in Swift

[Alex Blewitt via swift-users]

> On 10 Aug 2017, at 07:04, Mohit Athwani via swift-users 
>  wrote:
> 
> With closures being first class citizens in Swift and the ability of closures 
> to be able to capture scope, it seems a little archaic to me that the 
> #selector() feature exists in Swift. 
> 
> For example, why does
> func addTarget(_ target: Any?, 
> action: Selector 
> , 
>for controlEvents: UIControlEvents 
> )
> 
> have a Selector type for action. Why can’t action be defined to be a closure  
> for example:
> addTarget(_ target: Any?, 
> action: (sender: UIControl?, forEvent event:UIEvent?) -> Void, 
>for controlEvents: UIControlEvents 
> )
> 
> What do you guys think?

Selectors have been around since the start of the Objective-C platform, before 
either macOS or iOS existed. Blocks weren't added into macOS until relatively 
recently (from iOS 4 
https://en.wikipedia.org/wiki/Blocks_(C_language_extension) 
 if you're 
interested).

So many of the APIs that predated the introduction of blocks worked by having a 
selector that could be called back on a target, and these APIs are still 
present today in current releases of macOS and iOS.

The Swift based API is purely there because there are some APIs that aren't 
capable of taking a block, and hence aren't capable of taking a Swift closure.

Alex

___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users