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

2017-08-11 Thread Mohit Athwani via swift-users
Hi Alex,

Thanks for the update!

Cheers!


--
Mohit Athwani
http://about.me/mohitathwani

On Aug 10, 2017, 2:56 AM -0700, Alex Blewitt , wrote:
> > 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


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

2017-08-11 Thread Jens Persson via swift-users
Ok, thanks!
/Jens

On Fri, Aug 11, 2017 at 5:39 AM, Mishal Shah  wrote:

> 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 <
> swift-users@swift.org> 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] Simultaneous access to global tuple members

2017-08-11 Thread Martin R via swift-users
Thank you for the clarification.

> On 8. Aug 2017, at 18:39, Guillaume Lessard  
> wrote:
> 
> 
>> On Aug 8, 2017, at 09:10, Martin R  wrote:
>> 
>> In that example the tuple is a (stored) property of a class, not a global 
>> variable. And why does it crash for a global variable, but not for a local 
>> variable in a function?
> 
> In the case of a local variable in a function, the compiler can statically 
> prove that there is no simultaneous access, and using `swap` is allowed. With 
> a global variable, the compiler can’t statically prove exclusive access.
> (it seems silly with your simple example, but the system doesn’t try static 
> enforcement with global variables.)
> 
> Here’s another modification which traps at runtime:
> 
> ***
> import Dispatch
> 
> func foo()  {
>  var tuple = (1, 2)
> 
>  let q = DispatchQueue(label: "queue")
>  q.async { swap(, ) }
>  q.sync {}
> 
>  print(tuple)
> }
> 
> foo()
> ***
> 
> Guillaume Lessard
> 

___
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

2017-08-11 Thread Joanna Carter via swift-users
I really must do more research before making accusations ;-)

> Which still leaves my question of why I have to reimplement the default 
> copy(other:) method from the protocol's extension in the base class ???

Apparently, the answer is to remove the declaration of the copy(other:) method 
from the protocol itself and to leave the default implementation in the 
extension !

So I now end up with :

protocol Copyable
{
  init(other: Self)
}

extension Copyable
{
  func copy() -> Self
  {
return type(of: self).init(other: self)
  }
}


class Shape : Copyable
{
  var color: NSColor
  
  init(color: NSColor)
  {
self.color = color
  }
  
  required init(other: Shape)
  {
color = other.color
  }
}

… and all is well with the world :-)

Mind you, the compiler error messages were hardly helpful to diagnosing this 
particular problem :-(

Joanna

--
Joanna Carter
Carter Consulting

___
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

2017-08-11 Thread Joanna Carter via swift-users
> 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 {
> .
> }

But Copying does contain a Self requirement. It is used the result of the 
copy() method

Here is how I implement Copying :

protocol Copyable
{
  func copy() -> Self
  
  init(other: Self)
}

// This extension provides a default implementation
extension Copyable
{
  func copy() -> Self
  {
return type(of: self).init(other: self)
  }
}

implementing Copyable on a struct is simple :

struct Struct : Copyable
{
  var value: String
  
  init(value: String)
  {
self.value = value
  }
  
  init(other: Struct)
  {
value = other.value
  }
}

But implementing it on a class is slightly more troublesome.

class Shape : Copyable
{
  var color: NSColor
  
  init(color: NSColor)
  {
self.color = color
  }
}

At this stage, the compiler (obviously) screams that Copyable is not 
implemented but the first "error" it notices it marks as being on the default 
implementation in the extension:  Method 'copy()' in non-final class 'Shape' 
must return `Self` to conform to protocol 'Copyable'

Marking this error on the extension method, which obviously does exactly what 
the error says is missing ???

Implementing the copy() method in Shape kills this error message but leaves me 
wondering why I have to now repeat the exact same code in the implementing 
method that I wrote in the default method in the protocol extension ; something 
that the compiler is completely ignoring.

Implementing the protocol with a struct takes account of the default method but 
with a class ignores it. This smells remarkably like a bug !

Nonetheless, I now end up with the following code, complete with duplicate 
copy() method :

class Shape : Copyable
{
  var color: NSColor
  
  func copy() -> Self
  {
return type(of: self).init(other: self)
  }

  init(color: NSColor)
  {
self.color = color
  }
  
  required init(other: Shape)
  {
color = other.color
  }
}

Then I can go on to declare subclasses :

class Circle : Shape
{
  var radius: Double = 0.0
  
  init(color: NSColor, radius: Double)
  {
super.init(color: color)

self.radius = radius
  }

  required init(other: Shape)
  {
super.init(other: other)

if let other = other as? Circle
{
  radius = other.radius
}
  }
}


class Square : Shape
{
  var side: Double = 0.0
  
  init(color: NSColor, side: Double)
  {
super.init(color: color)

self.side = side
  }

  required init(other: Shape)
  {
super.init(other: other)

if let other = other as? Square
{
  side = other.side
}
  }
}

And, the, if I create an extension to Array :

extension Array where Element : Copyable
{
  func copy() -> Array
  {
var result = [Element]()

self.forEach { result.append($0.copy()) }

return result
  }
}

I can then use the following code to create an array of Shapes but, obviously 
not of Copyable, due to its restrictions on the Self requirements on the 
protocol.

{
  let shapes = [Circle(color: .black, radius: 5.0), Square(color: .black, side: 
5.0)]
  
  let copies = shapes.copy()
  
  …
}

Thus, another possible solution to your problem is to declare the required 
init(other: Self) in the protocol.

Which still leaves my question of why I have to reimplement the default 
copy(other:) method from the protocol's extension in the base class ???

Joanna

--
Joanna Carter
Carter Consulting

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