Re: [swift-users] Finding resources.

[Nate Birkholz via swift-users]

Hi, Moughees. This mailing list is for issues found developing with the
Swift language and not for help with third party frameworks such as Vapor.

Looking at the page for Vapor at https://github.com/vapor/vapor it seems
that they use a Slack channel for support. I would suggest you install a
Slack client and join their channel to get your questions answered.

On Mon, Oct 30, 2017 at 11:53 PM, moughees shah via swift-users <
swift-users@swift.org> wrote:

> I am very new to vapors and no nothing about it. I try to find some
> resources but don't find anything helping. Right now i am assigned to make
> a web form in vapor and because of lack of knowledge I am having trouble.
> I have to submit that as soon as possible.
> Will you please help me out.
>
> Thanks & Regards:
> Moughees Haider.
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>


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

Re: [swift-users] Expression was too complex to be solved in reasonable time

[Nate Birkholz via swift-users]

Thanks, Slava!

On Tue, Oct 24, 2017 at 3:05 PM, Slava Pestov <spes...@apple.com> wrote:

>
>
> On Oct 24, 2017, at 3:05 PM, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
> Doing a tutorial from RayWenderlich. https://www.
> raywenderlich.com/125313/make-game-like-candy-crush-spritekit-swift-part-4
>
> I have four bool values: topLeft, bottomLeft, topRight, and bottomRight
>
> the following line throws an error:
> let value = Int(topLeft.hashValue) | Int(topRight.hashValue) << 1 |
> Int(bottomLeft.hashValue) << 2 | Int(bottomRight.hashValue) << 3
>
>
> yeah,
>
> let value1 = Int(topRight.hashValue) << 1
> let value2 = Int(bottomLeft.hashValue) << 2
> let value3 = Int(bottomRight.hashValue) << 3
>
> let value = Int(topLeft.hashValue) | value1 | value2 | value3
>
>
> "Expression was too complex to be solved in reasonable time; consider
> breaking up the expression into distinct sub-expressions."
>
> This seems like a bug in the compiler, no? Is there actually a way to
> break that up?
>
>
> This is a known issue that got worse with the new integer oriented
> protocols, especially with shifts.
>
> Slava
>
>
> --
> Nate Birkholz
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>


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

[swift-users] Expression was too complex to be solved in reasonable time

[Nate Birkholz via swift-users]

Doing a tutorial from RayWenderlich.
https://www.raywenderlich.com/125313/make-game-like-candy-crush-spritekit-swift-part-4

I have four bool values: topLeft, bottomLeft, topRight, and bottomRight

the following line throws an error:
let value = Int(topLeft.hashValue) | Int(topRight.hashValue) << 1 |
Int(bottomLeft.hashValue) << 2 | Int(bottomRight.hashValue) << 3

"Expression was too complex to be solved in reasonable time; consider
breaking up the expression into distinct sub-expressions."

This seems like a bug in the compiler, no? Is there actually a way to break
that up?

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

[swift-users] Lifetime of objects in `class` methods

[Nate Birkholz via swift-users]

If I use these two classes:

class MotionManager {



class func doTheThing(completionHandler: @escaping (CMDeviceMotion?)->()
) {

print("in")

let manager = CMMotionManager()

manager.deviceMotionUpdateInterval = 0.01



manager.startDeviceMotionUpdates(to: .main) { (motion, error) in

print("out")

completionHandler(motion)

}

}

}


class OtherManager {

let manager: CMMotionManager



init() {

manager = CMMotionManager()

manager.deviceMotionUpdateInterval = 0.01

}



func doTheThing(completionHandler: @escaping (CMDeviceMotion?)->() ) {

print("in 2")

manager.startDeviceMotionUpdates(to: .main) { (motion , error) in

completionHandler(motion)

print("out 2")

self.manager.stopDeviceMotionUpdates()

}

}

}


let other = OtherManager()


other.doTheThing { (motion) in

print(motion)

}


MotionManager.doTheThing { (motion) in

print(motion)

}

The class method on MotionManager prints "in" but never prints "out". The
instance method version on. OtherManager works just fine, printing "in 2"
and "out 2". Clearly the CMMotionManager doesn't survive long enough to
finish its call, but I would have thought it would.

Is this a bug? Or am I just misunderstanding how the class method should
work?

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

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

on:). That's too bad, closure-based
>>> gesture recognizers would be snazzy and swifty and I'd love to see them as
>>> part of UIKit.
>>>
>>> I could write my own custom implementations of subclassed
>>> UIKit.UIGestureRecognizerSubclass(es), but as the screens in question
>>> have tap, swipe up, swipe down, and swipe right gesture recognizers, I feel
>>> its overkill to write all that to avoid repeating ~10 lines of code.
>>>
>>> On Sun, Jun 4, 2017 at 1:21 AM, Nate Birkholz <nbirkh...@gmail.com>
>>> wrote:
>>>
>>>> I briefly considered something like this but didn't explore it. Elegant.
>>>>
>>>> Sent from my iPhone, please excuse brevity and errors
>>>>
>>>> On Jun 3, 2017, at 9:38 PM, Geordie Jay <geo...@gmail.com> wrote:
>>>>
>>>> I am dealing with a variant of this on Android right now. I have just
>>>> subclassed e.g. UITapGestureRecognizer to perform the 2nd variant above and
>>>> externally accept a closure as its argument. I'm writing this on my phone
>>>> so forgive any syntax errors or accidental omissions:
>>>>
>>>> class TapGestureRecognizer: UITapGestureRecognizer {
>>>> var onTap: (() -> Void)?
>>>> init(onTap: (() -> Void)?) {
>>>> self.onTap = onTap
>>>> super.init(target: self, action: #selector(internalTapHandler))
>>>> }
>>>>
>>>> @objc private func internalTapHandler() {
>>>> onTap?()
>>>> }
>>>> }
>>>>
>>>> class Baz: Foo {
>>>> init() {
>>>> let tapRecognizer = TapGestureRecognizer(onTap: self.bar)
>>>> }
>>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Geordie
>>>> On Sat 3. Jun 2017 at 16:53, Nate Birkholz via swift-users <
>>>> swift-users@swift.org> wrote:
>>>>
>>>>> Thanks, the second had occurred to me, but felt a little too much like
>>>>> in practice it would make the code harder to understand.
>>>>>
>>>>> On Fri, Jun 2, 2017 at 9:58 PM, Zhao Xin <owe...@gmail.com> wrote:
>>>>>
>>>>>> I found two workarounds.
>>>>>>
>>>>>> 1.
>>>>>> protocol Foo: class {
>>>>>> func bar()
>>>>>> }
>>>>>>
>>>>>> class Base:Foo {
>>>>>> @objc func bar() {
>>>>>> print("bar")
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> class Baz: Base {
>>>>>> override init() {
>>>>>> super.init()
>>>>>> let tapRecognizer = UITapGestureRecognizer(target: self,
>>>>>> action: #selector(bar))
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> 2.
>>>>>> protocol Foo: class {
>>>>>> func bar()
>>>>>> }
>>>>>>
>>>>>> extension Foo {
>>>>>> func bar() {
>>>>>> print("bar")
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> class Baz: Foo {
>>>>>> init() {
>>>>>> let tapRecognizer = UITapGestureRecognizer(target: self,
>>>>>> action: #selector(delegate))
>>>>>> }
>>>>>>
>>>>>> @objc func delegate() {
>>>>>> bar()
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Zhao Xin
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jun 3, 2017 at 10:35 AM, Nate Birkholz via swift-users <
>>>>>> swift-users@swift.org> wrote:
>>>>>>
>>>>>>> protocol Foo: class {
>>>>>>> func bar()
>>>>>>> }
>>>>>>>
>>>>>>> extension Foo {
>>>>>>> func bar() {
>>>>>>>  print("bar")
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> class Baz: Foo {
>>>>>>> init() {
>>>>>>> let tapRecognizer = UITapGestureRecognizer(target: self,
>>>>>>> action: #selector(bar))
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> the #selector tells me: "Argument of '#selector' refers to instance
>>>>>>> method 'bar()' that is not exposed to Objective-C" and asks me to add 
>>>>>>> @objc
>>>>>>> to the method definition.
>>>>>>>
>>>>>>> Adding @objc to the method tells me: "@objc can only be used with
>>>>>>> members of classes, @objc protocols, and concrete extensions of classes"
>>>>>>>
>>>>>>> Adding @objc to the protocol doesn't fix it, just introduces new
>>>>>>> issues.
>>>>>>>
>>>>>>> "dynamic" cannot be applied to a protocol, so cannot be used
>>>>>>> alternatively.
>>>>>>>
>>>>>>> Is there a way to get around this? If a method is called by a
>>>>>>> gesture recognizer, is there no way to have a default protocol
>>>>>>> implementation? I'd like to use default implementations if possible to 
>>>>>>> make
>>>>>>> my code more DRY.
>>>>>>>
>>>>>>> Is there a roadmap/plan for swift-native selector dispatch?
>>>>>>>
>>>>>>> Thanks. I look forward to the inevitable reply revealing the dumb
>>>>>>> thing I missed. :)
>>>>>>>
>>>>>>> --
>>>>>>> Nate Birkholz
>>>>>>>
>>>>>>> ___
>>>>>>> swift-users mailing list
>>>>>>> swift-users@swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Nate Birkholz
>>>>> ___
>>>>> swift-users mailing list
>>>>> swift-users@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>>>
>>>>
>>>
>>>
>>> --
>>> Nate Birkholz
>>>
>>
>>
>>
>> --
>> Nate Birkholz
>>
>
>
>
>


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

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

Technically it does work(!), but I am hesitant to use it in what amounts to
sample code for my current job search, haha.

On Sun, Jun 4, 2017 at 4:55 AM, Zhao Xin <owe...@gmail.com> wrote:

> Will this work?
>
> class TapGestureRecognizer: UITapGestureRecognizer {
>
> var onTap: (() -> Void)?
>
> init(onTap: (() -> Void)?) {
>
> self.onTap = onTap
>
> super.init(target: nil, action: nil)
>
> *self.removeTarget(nil, action: nil)*
>
> self.addTarget(self, action: #selector(internalTapHandler))
>
> print(self)
>
> }
>
>
>
> @objc private func internalTapHandler() {
>
> onTap?()
>
> }
>
> }
>
> Zhao Xin
>
> On Sun, Jun 4, 2017 at 5:24 PM, Nate Birkholz <nbirkh...@gmail.com> wrote:
>
>> Also, note that I tried the following:
>>
>> class BlockTapGestureRecognizer: UIGestureRecognizer {
>> var onTap: (() -> Void)?
>> init(onTap: (() -> Void)?) {
>> self.onTap = onTap
>> super.init(target: nil, action: nil)
>> self.addTarget(self, action: #selector(internalTapHandler))
>> print(self)
>> }
>>
>> @objc private func internalTapHandler() {
>> onTap?()
>> }
>> }
>>
>> And the object prints looking okay:
>>
>> > UIGestureRecognizer; state = Possible; view = ; target=
>> <(action=internalTapHandler, target=> 0x1701998b0>)>>
>>
>> But it doesn't in practice work. The documentation for the (target:
>> action:) initializer states:
>>
>> target: An object that is the recipient of action messages sent by the
>> receiver when it recognizes a gesture. nil is not a valid value.
>> action: A selector that identifies the method implemented by the target
>> to handle the gesture recognized by the receiver. The action selector must
>> conform to the signature described in the class overview. NULL is not a
>> valid value.
>>
>> So something is going on inside there when the nil values are passed to
>> the recognizer. As the documentation states, nil is not a valid value and
>> it must cause troubles.
>>
>> Or I did something wrong?
>>
>>
>>
>> On Sun, Jun 4, 2017 at 1:55 AM, Nate Birkholz <nbirkh...@gmail.com>
>> wrote:
>>
>>> Ah, I didn't read the rest of the thread. As Zhao Xin notes, you cannot
>>> call super.init(target: self, action: #selector()), and you cannot call
>>> super.init() in a subclass init or convenience init, it *has* to be the
>>> designated init method init(target:action:). That's too bad, closure-based
>>> gesture recognizers would be snazzy and swifty and I'd love to see them as
>>> part of UIKit.
>>>
>>> I could write my own custom implementations of subclassed
>>> UIKit.UIGestureRecognizerSubclass(es), but as the screens in question
>>> have tap, swipe up, swipe down, and swipe right gesture recognizers, I feel
>>> its overkill to write all that to avoid repeating ~10 lines of code.
>>>
>>> On Sun, Jun 4, 2017 at 1:21 AM, Nate Birkholz <nbirkh...@gmail.com>
>>> wrote:
>>>
>>>> I briefly considered something like this but didn't explore it. Elegant.
>>>>
>>>> Sent from my iPhone, please excuse brevity and errors
>>>>
>>>> On Jun 3, 2017, at 9:38 PM, Geordie Jay <geo...@gmail.com> wrote:
>>>>
>>>> I am dealing with a variant of this on Android right now. I have just
>>>> subclassed e.g. UITapGestureRecognizer to perform the 2nd variant above and
>>>> externally accept a closure as its argument. I'm writing this on my phone
>>>> so forgive any syntax errors or accidental omissions:
>>>>
>>>> class TapGestureRecognizer: UITapGestureRecognizer {
>>>> var onTap: (() -> Void)?
>>>> init(onTap: (() -> Void)?) {
>>>> self.onTap = onTap
>>>> super.init(target: self, action: #selector(internalTapHandler))
>>>> }
>>>>
>>>> @objc private func internalTapHandler() {
>>>> onTap?()
>>>> }
>>>> }
>>>>
>>>> class Baz: Foo {
>>>> init() {
>>>> let tapRecognizer = TapGestureRecognizer(onTap: self.bar)
>>>> }
>>>> }
>>>>
>>>>
>>>> Cheers,
>>>> Geordie
>>>> On Sat 3. Jun 2017 at 16:53, Nate Birkholz via swift-users <
>>>> swift-users@swift.org>

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

Also, note that I tried the following:

class BlockTapGestureRecognizer: UIGestureRecognizer {
var onTap: (() -> Void)?
init(onTap: (() -> Void)?) {
self.onTap = onTap
super.init(target: nil, action: nil)
self.addTarget(self, action: #selector(internalTapHandler))
print(self)
}

@objc private func internalTapHandler() {
onTap?()
}
}

And the object prints looking okay:

; target=
<(action=internalTapHandler, target=)>>

But it doesn't in practice work. The documentation for the (target:
action:) initializer states:

target: An object that is the recipient of action messages sent by the
receiver when it recognizes a gesture. nil is not a valid value.
action: A selector that identifies the method implemented by the target to
handle the gesture recognized by the receiver. The action selector must
conform to the signature described in the class overview. NULL is not a
valid value.

So something is going on inside there when the nil values are passed to the
recognizer. As the documentation states, nil is not a valid value and it
must cause troubles.

Or I did something wrong?



On Sun, Jun 4, 2017 at 1:55 AM, Nate Birkholz <nbirkh...@gmail.com> wrote:

> Ah, I didn't read the rest of the thread. As Zhao Xin notes, you cannot
> call super.init(target: self, action: #selector()), and you cannot call
> super.init() in a subclass init or convenience init, it *has* to be the
> designated init method init(target:action:). That's too bad, closure-based
> gesture recognizers would be snazzy and swifty and I'd love to see them as
> part of UIKit.
>
> I could write my own custom implementations of subclassed UIKit.
> UIGestureRecognizerSubclass(es), but as the screens in question have tap,
> swipe up, swipe down, and swipe right gesture recognizers, I feel its
> overkill to write all that to avoid repeating ~10 lines of code.
>
> On Sun, Jun 4, 2017 at 1:21 AM, Nate Birkholz <nbirkh...@gmail.com> wrote:
>
>> I briefly considered something like this but didn't explore it. Elegant.
>>
>> Sent from my iPhone, please excuse brevity and errors
>>
>> On Jun 3, 2017, at 9:38 PM, Geordie Jay <geo...@gmail.com> wrote:
>>
>> I am dealing with a variant of this on Android right now. I have just
>> subclassed e.g. UITapGestureRecognizer to perform the 2nd variant above and
>> externally accept a closure as its argument. I'm writing this on my phone
>> so forgive any syntax errors or accidental omissions:
>>
>> class TapGestureRecognizer: UITapGestureRecognizer {
>> var onTap: (() -> Void)?
>> init(onTap: (() -> Void)?) {
>> self.onTap = onTap
>> super.init(target: self, action: #selector(internalTapHandler))
>> }
>>
>> @objc private func internalTapHandler() {
>> onTap?()
>> }
>> }
>>
>> class Baz: Foo {
>> init() {
>> let tapRecognizer = TapGestureRecognizer(onTap: self.bar)
>> }
>> }
>>
>>
>> Cheers,
>> Geordie
>> On Sat 3. Jun 2017 at 16:53, Nate Birkholz via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> Thanks, the second had occurred to me, but felt a little too much like
>>> in practice it would make the code harder to understand.
>>>
>>> On Fri, Jun 2, 2017 at 9:58 PM, Zhao Xin <owe...@gmail.com> wrote:
>>>
>>>> I found two workarounds.
>>>>
>>>> 1.
>>>>
>>>> protocol Foo: class {
>>>>
>>>> func bar()
>>>>
>>>> }
>>>>
>>>>
>>>> class Base:Foo {
>>>>
>>>> @objc func bar() {
>>>>
>>>> print("bar")
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> class Baz: Base {
>>>>
>>>> override init() {
>>>>
>>>> super.init()
>>>>
>>>>         let tapRecognizer = UITapGestureRecognizer(target: self,
>>>> action: #selector(bar))
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>> 2.
>>>>
>>>> protocol Foo: class {
>>>>
>>>> func bar()
>>>>
>>>> }
>>>>
>>>>
>>>> extension Foo {
>>>>
>>>> func bar() {
>>>>
>>>> print("bar")
>>>>
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> class Baz: Foo {
>>>>
>>>> init

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

Ah, I didn't read the rest of the thread. As Zhao Xin notes, you cannot
call super.init(target: self, action: #selector()), and you cannot call
super.init() in a subclass init or convenience init, it *has* to be the
designated init method init(target:action:). That's too bad, closure-based
gesture recognizers would be snazzy and swifty and I'd love to see them as
part of UIKit.

I could write my own custom implementations of subclassed
UIKit.UIGestureRecognizerSubclass(es), but as the screens in question have
tap, swipe up, swipe down, and swipe right gesture recognizers, I feel its
overkill to write all that to avoid repeating ~10 lines of code.

On Sun, Jun 4, 2017 at 1:21 AM, Nate Birkholz <nbirkh...@gmail.com> wrote:

> I briefly considered something like this but didn't explore it. Elegant.
>
> Sent from my iPhone, please excuse brevity and errors
>
> On Jun 3, 2017, at 9:38 PM, Geordie Jay <geo...@gmail.com> wrote:
>
> I am dealing with a variant of this on Android right now. I have just
> subclassed e.g. UITapGestureRecognizer to perform the 2nd variant above and
> externally accept a closure as its argument. I'm writing this on my phone
> so forgive any syntax errors or accidental omissions:
>
> class TapGestureRecognizer: UITapGestureRecognizer {
> var onTap: (() -> Void)?
> init(onTap: (() -> Void)?) {
> self.onTap = onTap
> super.init(target: self, action: #selector(internalTapHandler))
> }
>
> @objc private func internalTapHandler() {
> onTap?()
> }
> }
>
> class Baz: Foo {
> init() {
> let tapRecognizer = TapGestureRecognizer(onTap: self.bar)
> }
> }
>
>
> Cheers,
> Geordie
> On Sat 3. Jun 2017 at 16:53, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
>> Thanks, the second had occurred to me, but felt a little too much like in
>> practice it would make the code harder to understand.
>>
>> On Fri, Jun 2, 2017 at 9:58 PM, Zhao Xin <owe...@gmail.com> wrote:
>>
>>> I found two workarounds.
>>>
>>> 1.
>>>
>>> protocol Foo: class {
>>>
>>> func bar()
>>>
>>> }
>>>
>>>
>>> class Base:Foo {
>>>
>>> @objc func bar() {
>>>
>>> print("bar")
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> class Baz: Base {
>>>
>>> override init() {
>>>
>>> super.init()
>>>
>>> let tapRecognizer = UITapGestureRecognizer(target: self,
>>> action: #selector(bar))
>>>
>>> }
>>>
>>> }
>>>
>>> 2.
>>>
>>> protocol Foo: class {
>>>
>>> func bar()
>>>
>>> }
>>>
>>>
>>> extension Foo {
>>>
>>> func bar() {
>>>
>>> print("bar")
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> class Baz: Foo {
>>>
>>> init() {
>>>
>>> let tapRecognizer = UITapGestureRecognizer(target: self,
>>> action: #selector(delegate))
>>>
>>> }
>>>
>>>
>>>
>>> @objc func delegate() {
>>>
>>> bar()
>>>
>>> }
>>>
>>> }
>>>
>>>
>>> Zhao Xin
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jun 3, 2017 at 10:35 AM, Nate Birkholz via swift-users <
>>> swift-users@swift.org> wrote:
>>>
>>>> protocol Foo: class {
>>>> func bar()
>>>> }
>>>>
>>>> extension Foo {
>>>> func bar() {
>>>>  print("bar")
>>>> }
>>>> }
>>>>
>>>> class Baz: Foo {
>>>> init() {
>>>> let tapRecognizer = UITapGestureRecognizer(target: self,
>>>> action: #selector(bar))
>>>> }
>>>> }
>>>>
>>>> the #selector tells me: "Argument of '#selector' refers to instance
>>>> method 'bar()' that is not exposed to Objective-C" and asks me to add @objc
>>>> to the method definition.
>>>>
>>>> Adding @objc to the method tells me: "@objc can only be used with
>>>> members of classes, @objc protocols, and concrete extensions of classes"
>>>>
>>>> Adding @objc to the protocol doesn't fix it, just introduces new issues.
>>>>
>>>> "dynamic" cannot be applied to a protocol, so cannot be used
>>>> alternatively.
>>>>
>>>> Is there a way to get around this? If a method is called by a gesture
>>>> recognizer, is there no way to have a default protocol implementation? I'd
>>>> like to use default implementations if possible to make my code more DRY.
>>>>
>>>> Is there a roadmap/plan for swift-native selector dispatch?
>>>>
>>>> Thanks. I look forward to the inevitable reply revealing the dumb thing
>>>> I missed. :)
>>>>
>>>> --
>>>> Nate Birkholz
>>>>
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>>
>>>>
>>>
>>
>>
>> --
>> Nate Birkholz
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>


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

Re: [swift-users] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

I briefly considered something like this but didn't explore it. Elegant.

Sent from my iPhone, please excuse brevity and errors

> On Jun 3, 2017, at 9:38 PM, Geordie Jay <geo...@gmail.com> wrote:
> 
> I am dealing with a variant of this on Android right now. I have just 
> subclassed e.g. UITapGestureRecognizer to perform the 2nd variant above and 
> externally accept a closure as its argument. I'm writing this on my phone so 
> forgive any syntax errors or accidental omissions:
> 
> class TapGestureRecognizer: UITapGestureRecognizer {
> var onTap: (() -> Void)?
> init(onTap: (() -> Void)?) {
> self.onTap = onTap
> super.init(target: self, action: #selector(internalTapHandler))
> }
> 
> @objc private func internalTapHandler() {
> onTap?()
> }
> }
> 
> class Baz: Foo {
> init() {
> let tapRecognizer = TapGestureRecognizer(onTap: self.bar)
> }
> }
> 
> 
> Cheers,
> Geordie
>> On Sat 3. Jun 2017 at 16:53, Nate Birkholz via swift-users 
>> <swift-users@swift.org> wrote:
>> Thanks, the second had occurred to me, but felt a little too much like in 
>> practice it would make the code harder to understand.
>> 
>>> On Fri, Jun 2, 2017 at 9:58 PM, Zhao Xin <owe...@gmail.com> wrote:
>>> I found two workarounds.
>>> 
>>> 1.
>>> protocol Foo: class {
>>> func bar()
>>> }
>>> 
>>> class Base:Foo {
>>> @objc func bar() {
>>> print("bar")
>>> }
>>> }
>>> 
>>> class Baz: Base {
>>> override init() {
>>> super.init()
>>> let tapRecognizer = UITapGestureRecognizer(target: self, action: 
>>> #selector(bar))
>>> }
>>> }
>>> 
>>> 2.
>>> protocol Foo: class {
>>> func bar()
>>> }
>>> 
>>> extension Foo {
>>> func bar() {
>>> print("bar")
>>> }
>>> }
>>> 
>>> class Baz: Foo {
>>> init() {
>>> let tapRecognizer = UITapGestureRecognizer(target: self, action: 
>>> #selector(delegate))
>>> }
>>> 
>>> @objc func delegate() {
>>> bar()
>>> }
>>> }
>>> 
>>> 
>>> Zhao Xin
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> On Sat, Jun 3, 2017 at 10:35 AM, Nate Birkholz via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> protocol Foo: class {
>>>> func bar()
>>>> }
>>>> 
>>>> extension Foo {
>>>> func bar() {
>>>>  print("bar")
>>>> }
>>>> }
>>>> 
>>>> class Baz: Foo {
>>>> init() {
>>>> let tapRecognizer = UITapGestureRecognizer(target: self, action: 
>>>> #selector(bar))
>>>> }
>>>> }
>>>> 
>>>> the #selector tells me: "Argument of '#selector' refers to instance method 
>>>> 'bar()' that is not exposed to Objective-C" and asks me to add @objc to 
>>>> the method definition. 
>>>> 
>>>> Adding @objc to the method tells me: "@objc can only be used with members 
>>>> of classes, @objc protocols, and concrete extensions of classes"
>>>> 
>>>> Adding @objc to the protocol doesn't fix it, just introduces new issues.
>>>> 
>>>> "dynamic" cannot be applied to a protocol, so cannot be used 
>>>> alternatively. 
>>>> 
>>>> Is there a way to get around this? If a method is called by a gesture 
>>>> recognizer, is there no way to have a default protocol implementation? I'd 
>>>> like to use default implementations if possible to make my code more DRY.
>>>> 
>>>> Is there a roadmap/plan for swift-native selector dispatch?
>>>> 
>>>> Thanks. I look forward to the inevitable reply revealing the dumb thing I 
>>>> missed. :)
>>>> 
>>>> -- 
>>>> Nate Birkholz
>>>> 
>>>> ___
>>>> swift-users mailing list
>>>> swift-users@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-users
>>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Nate Birkholz
>> ___
>> 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] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

Thanks, the second had occurred to me, but felt a little too much like in
practice it would make the code harder to understand.

On Fri, Jun 2, 2017 at 9:58 PM, Zhao Xin <owe...@gmail.com> wrote:

> I found two workarounds.
>
> 1.
>
> protocol Foo: class {
>
> func bar()
>
> }
>
>
> class Base:Foo {
>
> @objc func bar() {
>
> print("bar")
>
> }
>
> }
>
>
> class Baz: Base {
>
> override init() {
>
> super.init()
>
> let tapRecognizer = UITapGestureRecognizer(target: self, action:
> #selector(bar))
>
> }
>
> }
>
> 2.
>
> protocol Foo: class {
>
> func bar()
>
> }
>
>
> extension Foo {
>
> func bar() {
>
> print("bar")
>
> }
>
> }
>
>
> class Baz: Foo {
>
> init() {
>
> let tapRecognizer = UITapGestureRecognizer(target: self, action:
> #selector(delegate))
>
> }
>
>
>
> @objc func delegate() {
>
> bar()
>
> }
>
> }
>
>
> Zhao Xin
>
>
>
>
>
>
> On Sat, Jun 3, 2017 at 10:35 AM, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
>> protocol Foo: class {
>> func bar()
>> }
>>
>> extension Foo {
>> func bar() {
>>  print("bar")
>> }
>> }
>>
>> class Baz: Foo {
>> init() {
>> let tapRecognizer = UITapGestureRecognizer(target: self, action:
>> #selector(bar))
>> }
>> }
>>
>> the #selector tells me: "Argument of '#selector' refers to instance
>> method 'bar()' that is not exposed to Objective-C" and asks me to add @objc
>> to the method definition.
>>
>> Adding @objc to the method tells me: "@objc can only be used with members
>> of classes, @objc protocols, and concrete extensions of classes"
>>
>> Adding @objc to the protocol doesn't fix it, just introduces new issues.
>>
>> "dynamic" cannot be applied to a protocol, so cannot be used
>> alternatively.
>>
>> Is there a way to get around this? If a method is called by a gesture
>> recognizer, is there no way to have a default protocol implementation? I'd
>> like to use default implementations if possible to make my code more DRY.
>>
>> Is there a roadmap/plan for swift-native selector dispatch?
>>
>> Thanks. I look forward to the inevitable reply revealing the dumb thing I
>> missed. :)
>>
>> --
>> Nate Birkholz
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>


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

[swift-users] Calling default implementation of protocol methods as selectors

[Nate Birkholz via swift-users]

protocol Foo: class {
func bar()
}

extension Foo {
func bar() {
 print("bar")
}
}

class Baz: Foo {
init() {
let tapRecognizer = UITapGestureRecognizer(target: self, action:
#selector(bar))
}
}

the #selector tells me: "Argument of '#selector' refers to instance method
'bar()' that is not exposed to Objective-C" and asks me to add @objc to the
method definition.

Adding @objc to the method tells me: "@objc can only be used with members
of classes, @objc protocols, and concrete extensions of classes"

Adding @objc to the protocol doesn't fix it, just introduces new issues.

"dynamic" cannot be applied to a protocol, so cannot be used alternatively.

Is there a way to get around this? If a method is called by a gesture
recognizer, is there no way to have a default protocol implementation? I'd
like to use default implementations if possible to make my code more DRY.

Is there a roadmap/plan for swift-native selector dispatch?

Thanks. I look forward to the inevitable reply revealing the dumb thing I
missed. :)

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

Re: [swift-users] Passing value types or members of value types?

[Nate Birkholz via swift-users]

Classes and structs are different things. Classes are passed by reference,
structs are passed by value with copy on write.

Strings and Arrays are structs, not classes.

On Sat, May 6, 2017 at 10:24 PM, Kelvin Ma  wrote:

> I hear that a lot but why do all the official sources sound like
> copy-on-write is something you have to manually implement with a class and
> isUniquelyReferenced if it’s not an array or a string?
>
> On May 7, 2017, at 12:02 AM, Nate Birkholz  wrote:
>
> Let me try one more time, my stupid phone keeps changing words.
>
> ACTUALLY, the struct is a pointer until it's written to, and is only
> copied on write.
>
> Sent from my iPhone, please excuse brevity and errors
>
> On May 6, 2017, at 9:59 PM, Nate Birkholz  wrote:
>
> Oddly, until it's *written* you will be working with a pointer.
>
> Sent from my iPhone, please excuse brevity and errors
>
> On May 6, 2017, at 9:33 PM, Kelvin Ma via swift-users <
> swift-users@swift.org> wrote:
>
> If I have a “large” struct like
>
> struct Vertex
> {
> let x:Double, y:Double
> var r:Int, g:Int, b:Int
> let s:Double, t:Double
> var selected:Bool
> }
>
> and I want to pass it to a function without modifying it like
>
> func taxicab_distance(_ v1:Vertex, _ v2:Vertex) -> Double
> {
> return v2.x - v1.x + v2.y - v1.y
> }
>
> Will the entire struct Vertex get copied and pushed onto the stack, or
> will only the relevant members be passed to the function?
>
> In other words, does the compiler know to optimize this call down to
>
> func taxicab_distance(v2x:Double, v1x:Double, v2y:Double, v1y:Double) ->
> Double
> {
> return v2x - v1x + v2y - v1y
> }
>
> ?
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>


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

Re: [swift-users] edit array

[Nate Birkholz via swift-users]

Relatively straightforward to write this, which usually has meant "no" to 
adding something to the standard library. (Not that I agree with that measure.)

Sent from my iPhone, please excuse brevity and errors

> On Apr 26, 2017, at 11:13 AM, Ole Begemann via swift-users 
>  wrote:
> 
> On 26.04.2017 17:01, J.E. Schotsman via swift-users wrote:
>>> On 26 Apr 2017, at 16:54, Rien  wrote:
>>> 
>>> Agree, though the function should probably be named something like: 
>>> withEach instead of forEach.
>>> Maybe worth a proposal on evolution?
>> Let’s wait until the people at the other side of the big lake have had time 
>> to react.
> 
> There have been requests for something like this on swift-evolution, e.g. 
> here in the context of the discussion about a `reduce` variant that takes 
> `inout` arguments: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030641.html
> 
> An alternative might be to add a variant of `map` to `MutableCollection` that 
> mutates the collection directly, see: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170123/030643.html.
> 
> But as far as I know there hasn't been a proposal for adding this. (Is it 
> important enough to have in the standard library? I don't know.)
> 
> ___
> 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] odd `==` `!=` behavior with class that inherits `NSObject`

[Nate Birkholz via swift-users]

I'm not sure exactly how class declarations interact with the scope of a
do{ } statement. I declare a new static function inside your do{ } scope
and it works fine, but something about the mapping of `==` and `!=` to
`isEqual` in NSObject seems to be confused by the scope of the do{ } block.

I'm not sure what the use case is for declaring a class inside a do{ }
block, but it seems like a bug with SNObject operator mapping:

//: Playground - noun: a place where people can play


import UIKit


do{

class Foo:NSObject {

let name:String


init(name:String) {

self.name = name

}


public static func testStatic(_ object: Foo) {

print(object.name)

}


public static func ==(lhs: Foo, rhs: Foo) -> Bool {

guard type(of:lhs) == type(of:rhs) else { return false }

return lhs.name == rhs.name

}


public static func !=(lhs: Foo, rhs: Foo) -> Bool {

guard type(of:lhs) == type(of:rhs) else { return false }

return lhs.name != rhs.name

}


override func isEqual(_ object: Any?) -> Bool {

print("in isEqual")

guard let object = object as? Foo else { return false }

let _ = super.isEqual(object)

if self.name == object.name {

return true

}


return false

}

}


let a = Foo(name: "bar")

let b = Foo(name: "bar")


print(a == b) // true

print(a != b) // false


Foo.testStatic(a) // bar

}


output is:

in isEqual

true

in isEqual

false

bar


For the record, enclosing just the statements *outside* the class
declaration in a do{ } block works as expected:

class Foo:NSObject {

let name:String


init(name:String) {

self.name = name

}


public static func ==(lhs: Foo, rhs: Foo) -> Bool {

guard type(of:lhs) == type(of:rhs) else { return false }

return lhs.name == rhs.name

}


public static func !=(lhs: Foo, rhs: Foo) -> Bool {

guard type(of:lhs) == type(of:rhs) else { return false }

return lhs.name != rhs.name

}


override func isEqual(_ object: Any?) -> Bool {

print("in isEqual")

guard let object = object as? Foo else { return false }

let _ = super.isEqual(object)

if self.name == object.name {

return true

}


return false

}

}

do{

let a = Foo(name: "bar")

let b = Foo(name: "bar")


print(a == b) // true

print(a != b) // false

}


output:

true

false


On Tue, Apr 18, 2017 at 8:07 PM, Zhao Xin  wrote:

> Just put your code in to a do-block. The result will be opposite.
>
>
> do {
>
>
>
> class Foo:NSObject {
>
> let name:String
>
>
>
> init(name:String) {
>
> self.name = name
>
> }
>
>
>
> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>
> guard type(of:lhs) == type(of:rhs) else { return false }
>
> return lhs.name == rhs.name
>
> }
>
>
>
> public static func !=(lhs: Foo, rhs: Foo) -> Bool {
>
> guard type(of:lhs) == type(of:rhs) else { return false }
>
> return lhs.name != rhs.name
>
> }
>
> }
>
>
>
> let a = Foo(name: "bar")
>
> let b = Foo(name: "bar")
>
>
>
> print(a == b) // true, now false
>
> print(a != b) // false, now true
>
> }
>
>
> Zhaoxin
>
> On Wed, Apr 19, 2017 at 11:04 AM, Nate Birkholz 
> wrote:
>
>> Your issue seems to be that you created a custom implementation for the
>> `==` operator but not one for the `!=` operator. If I add a custom
>> implementation for `!=` I get the results you expected. Tthe default
>> implementation of NSObject's `isEqual` is a test for identity, like the
>> `===` in Swift. So when you ask "is `a` NOT the same object in memory as
>> `b`?" the object returns "true" because they are indeed not the same object.
>>
>> class Foo:NSObject {
>>
>> let name:String
>>
>>
>> init(name:String) {
>>
>> self.name = name
>>
>> }
>>
>>
>> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>>
>> guard type(of:lhs) == type(of:rhs) else { return false }
>>
>> return lhs.name == rhs.name
>>
>> }
>>
>>
>> public static func !=(lhs: Foo, rhs: Foo) -> Bool {
>>
>> guard type(of:lhs) == type(of:rhs) else { return false }
>>
>> return lhs.name != rhs.name
>>
>> }
>>
>> }
>>
>>
>> let a = Foo(name: "bar")
>>
>> let b = Foo(name: "bar")
>>
>>
>> print(a == b) // true
>>
>> print(a != b) // false
>>
>> On Tue, Apr 18, 2017 at 7:33 PM, Zhao Xin via swift-users <
>> swift-users@swift.org> wrote:
>>
>>> Sample 1: both `==` and `!=` is true.
>>>
>>> import Foundation
>>>
>>>
>>> class Foo:NSObject {
>>>
>>> let name:String
>>>
>>>
>>> init(name:String) {
>>>
>>> self.name = name
>>>
>>> }
>>>
>>>
>>> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>>>
>>> guard type(of:lhs) == 

Re: [swift-users] odd `==` `!=` behavior with class that inherits `NSObject`

[Nate Birkholz via swift-users]

Your issue seems to be that you created a custom implementation for the
`==` operator but not one for the `!=` operator. If I add a custom
implementation for `!=` I get the results you expected. Tthe default
implementation of NSObject's `isEqual` is a test for identity, like the
`===` in Swift. So when you ask "is `a` NOT the same object in memory as
`b`?" the object returns "true" because they are indeed not the same object.

class Foo:NSObject {

let name:String


init(name:String) {

self.name = name

}


public static func ==(lhs: Foo, rhs: Foo) -> Bool {

guard type(of:lhs) == type(of:rhs) else { return false }

return lhs.name == rhs.name

}


public static func !=(lhs: Foo, rhs: Foo) -> Bool {

guard type(of:lhs) == type(of:rhs) else { return false }

return lhs.name != rhs.name

}

}


let a = Foo(name: "bar")

let b = Foo(name: "bar")


print(a == b) // true

print(a != b) // false

On Tue, Apr 18, 2017 at 7:33 PM, Zhao Xin via swift-users <
swift-users@swift.org> wrote:

> Sample 1: both `==` and `!=` is true.
>
> import Foundation
>
>
> class Foo:NSObject {
>
> let name:String
>
>
> init(name:String) {
>
> self.name = name
>
> }
>
>
> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>
> guard type(of:lhs) == type(of:rhs) else { return false }
>
> return lhs.name == rhs.name
>
> }
>
> }
>
>
> let a = Foo(name: "bar")
>
> let b = Foo(name: "bar")
>
>
> print(a == b) // true
>
> print(a != b) // true
>
> Sample 2: Add above code to a do-block, behavior changes to expect
>
> do {
>
> class Foo:NSObject {
>
> let name:String
>
>
>
> init(name:String) {
>
> self.name = name
>
> }
>
>
>
> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>
> guard type(of:lhs) == type(of:rhs) else { return false }
>
> return lhs.name == rhs.name
>
> }
>
> }
>
>
>
> let a = Foo(name: "bar")
>
> let b = Foo(name: "bar")
>
>
>
> print(a == b) // false
>
> print(a != b) // true
>
> }
>
> Sample 3: A little investigation shows that `==` didn't call NSObject's `
> func isEqual(_ object: Any?) -> Bool` but `!=` did.
>
> class Foo:NSObject {
>
> let name:String
>
>
>
> init(name:String) {
>
> self.name = name
>
> }
>
>
>
> public static func ==(lhs: Foo, rhs: Foo) -> Bool {
>
> guard type(of:lhs) == type(of:rhs) else { return false }
>
> return lhs.name == rhs.name
>
> }
>
>
>
> override func isEqual(to object: Any?) -> Bool {
>
> print("111")
>
> return super.isEqual(to: object)
>
> }
>
>
>
> override func isEqual(_ object: Any?) -> Bool {
>
> print("")
>
> return super.isEqual(object)
>
> }
>
> }
>
>
> let a = Foo(name: "bar")
>
> let b = Foo(name: "bar")
>
>
> print(a == b) // true
>
> print(a != b) // , true
>
> print(!(a == b)) // false
>
>
> So I am wondering what is the future? Will we keep on using `isEqual(_
>  object: Any?)` with class that inherits `NSObject`, or we are trying to
> drop it?
>
> Xcode  8.3.1 (8E1000a), 3.1 (swiftlang-802.0.51 clang-802.0.41), macOS 10.12.4
> (16E195)
>
> Zhaoxin
>
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>


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

Re: [swift-users] Get class of object in Swift 2.3

[Nate Birkholz via swift-users]

Never mind, .dynamicType works, it just doesn't autocomplete any more.
/facepalm

On Thu, Nov 10, 2016 at 11:54 AM, Nate Birkholz  wrote:

> self.dynamicType doesn't work any more, but type(of: self) is just Swift
> 3.0 So how do i get the class?
>
> Use case in a unit test:
>
> let bundle = NSBundle(forClass: type(of: self))
>
> --
> Nate Birkholz
>



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

[swift-users] Get class of object in Swift 2.3

[Nate Birkholz via swift-users]

self.dynamicType doesn't work any more, but type(of: self) is just Swift
3.0 So how do i get the class?

Use case in a unit test:

let bundle = NSBundle(forClass: type(of: self))

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

Re: [swift-users] Swift migration bug

[Nate Birkholz via swift-users]

No worries, since it was related to changing Swift syntax I thought it might 
end up being in some schema file maintained by the Swift team, thus the 
original question. :) Easy enough to add it to my list of radars.

Sent from my iPhone, please excuse brevity and errors

> On Oct 3, 2016, at 3:59 PM, Jordan Rose <jordan_r...@apple.com> wrote:
> 
> Ha, sorry to get to these in the wrong order. The real rule is "is the 
> feature part of the Swift Open Source project", but certainly a normal Xcode 
> user isn't thinking about whether the command they just used "came from 
> Xcode" or "came from Swift".
> 
> Radars will always get to Apple Swift people if it turns out to be a Swift 
> issue, but bugs.swift.org has fewer communication restrictions and allows 
> non-Apple people to help. If it's not clearly a Swift issue ("the compiler 
> crashed") or an Xcode issue ("I can't open my project"), it's a toss-up. But 
> no harm done (and thanks for reporting the bug in the first place).
> 
> Jordan
> 
> P.S. Why did I ask you to file the bug at bugreport.apple.com yourself? 
> Because if I did it then you'd never hear when it was fixed, and wouldn't get 
> the chance to test it on your own code and say "no, you fixed the wrong 
> thing". :-)
> 
> 
>> On Oct 3, 2016, at 10:12, Nate Birkholz via swift-users 
>> <swift-users@swift.org> wrote:
>> 
>> Then Jordan Rose closed it as not a Swift bug. :)
>> 
>> On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt <alb...@apple.com> wrote:
>>>> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users 
>>>> <swift-users@swift.org> wrote:
>>>> 
>>>> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug 
>>>> goes to swift.org or to Apple.
>>>> 
>>>> UI test generator uses the syntax (XCUIElement).children(matching: .other) 
>>>> but the compiler only recognizes childrenMatchingType(.Other), and you 
>>>> have to manually change the instances. Makes generating UI Tests a pain!
>>> 
>>> Please open a bug at https://bugs.swift.org and then it can be re-routed if 
>>> necessary. If you can attach the snippet of code with before/after that 
>>> would help.
>>> 
>>> Thanks!
>>> 
>>> Alex
>>> 
>> 
>> 
>> 
>> -- 
>> Nate Birkholz
>> ___
>> 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 migration bug

[Nate Birkholz via swift-users]

https://bugs.swift.org/browse/SR-2837

On Mon, Oct 3, 2016 at 2:03 AM, Alex Blewitt <alb...@apple.com> wrote:

> On 30 Sep 2016, at 19:30, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
> I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug
> goes to swift.org or to Apple.
>
> UI test generator uses the syntax (XCUIElement).children(matching:
> .other) but the compiler only recognizes childrenMatchingType(.Other), and
> you have to manually change the instances. Makes generating UI Tests a pain!
>
>
> Please open a bug at https://bugs.swift.org and then it can be re-routed
> if necessary. If you can attach the snippet of code with before/after that
> would help.
>
> Thanks!
>
> Alex
>
>


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

[swift-users] Swift migration bug

[Nate Birkholz via swift-users]

I found a bug in Swift 2.3 migration in the XCUITests, not sure if the bug
goes to swift.org or to Apple.

UI test generator uses the syntax (XCUIElement).children(matching: .other)
but the compiler only recognizes childrenMatchingType(.Other), and you have
to manually change the instances. Makes generating UI Tests a pain!



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

Re: [swift-users] Is there method indiicate current thread is mainthread in swift?

[Nate Birkholz via swift-users]

Is this a change to NSThread in the release, or to the language, dropping
empty () when calling methods? If the latter, what proposal is it? i can't
find it.

On Wed, Jul 13, 2016 at 12:41 AM, Jose Cheyo Jimenez via swift-users <
swift-users@swift.org> wrote:

> //swift 2.2+
> NSThread.isMainThread()
>
> //swift 3+
> Thread.isMainThread
>
>
> On Jul 13, 2016, at 12:27 AM, qi bo via swift-users 
> wrote:
>
> isMainThread is an method in object-c. how to indicate current thread is
> main thread?
>
> thank you
> Bob
> ___
> 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
>
>


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

Re: [swift-users] Switch based on let

[Nate Birkholz via swift-users]

Much obliged!! This syntax is clean and makes sense once I see it.

Sent from my iPhone, please excuse brevity and errors

> On Jul 8, 2016, at 8:49 AM, Dan Loewenherz via swift-users 
> <swift-users@swift.org> wrote:
> 
>> On Fri, Jul 8, 2016 at 10:34 AM, Roth Michaels via swift-users 
>> <swift-users@swift.org> wrote:
>> On Fri, Jul 08 2016 at 11:11:04 AM, Nate Birkholz via swift-users 
>> <swift-users@swift.org> wrote:
>> > This gives an error, expecting a colon (:) after object on every case.
>> >
>> > I wanted to be sure I wasn't missing something in my syntax (nor some
>> > obvious-to-others reason this isn't supported) before going to swift
>> > evolution.
>> 
>> There is a bug filed to improve this error message:
>> https://bugs.swift.org/browse/SR-2022
>> 
>> On Fri, Jul 08 2016 at 11:15:48 AM, Dan Loewenherz via swift-users 
>> <swift-users@swift.org> wrote:
>> > To my knowledge, you can’t do exactly what you’re trying to do
>> 
>> Here is how:
>> 
>> ```Swift
>> 
>> for object in objects {
>> switch object {
>> case let object as Subclass1:
>> doSomethingWith(object)
>> case let object as Subclass2:
>> doSomethingWith(object)
>> case let object as Subclass3:
>> doSomethingWith(object)
>> default:
>> break
>> }
>> }
> 
> Beautiful, thanks Roth! This is much nicer. :)
> 
> Dan
> ___
> 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] Switch based on let

[Nate Birkholz via swift-users]

Thanks, I never seem to know when to use .self.

On Fri, Jul 8, 2016 at 8:15 AM, Dan Loewenherz <d...@lionheartsw.com> wrote:

> To my knowledge, you can’t do exactly what you’re trying to do, but this
> is close:
>
> for subclassObject in objects {
>
> switch subclassObject.self {
>
> case is Subclass1:
>
> doSomethingWith(subclassObject as! Subclass1)
>
>
> case is Subclass2:
>
> doSomethingWith(subclassObject as! Subclass2)
>
>
> case is Subclass3:
>
> doSomethingWith(subclassObject as! Subclass3)
>
>
> default:
>
>     break
>
> }
>
> }
>
> On Fri, Jul 8, 2016 at 10:11 AM, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
>> This looks like it doesn't work (swift 2.x), but wanted to be sure it's
>> not supported:
>>
>> class Superclass {}
>> class Subclass1 : Superclass {}
>> class Subclass2 : Superclass {}
>> class Subclass3 : Superclass {}
>>
>> let sc1 = Subclass1()
>> let sc2 = Subclass2()
>> let sc3 = Subclass3()
>>
>> let objects : [Superclass] = [sc1, sc2, sc3]
>>
>> for subclassObject in objects {
>> switch subclassObject {
>> case let object = subclassObject as? Subclass1:
>> doSomethingWith(object)
>> case let object = subclassObject as? Subclass2:
>> doSomethingWith(object)
>> case let object = subclassObject as? Subclass3:
>> doSomethingWith(object)
>> default:
>> return
>> }
>> }
>> This gives an error, expecting a colon (:) after object on every case.
>>
>> I wanted to be sure I wasn't missing something in my syntax (nor some
>> obvious-to-others reason this isn't supported) before going to swift
>> evolution.
>>
>>
>> --
>> Nate Birkholz
>>
>> ___
>> swift-users mailing list
>> swift-users@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>>
>>
>


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

[swift-users] Switch based on let

[Nate Birkholz via swift-users]

This looks like it doesn't work (swift 2.x), but wanted to be sure it's not
supported:

class Superclass {}
class Subclass1 : Superclass {}
class Subclass2 : Superclass {}
class Subclass3 : Superclass {}

let sc1 = Subclass1()
let sc2 = Subclass2()
let sc3 = Subclass3()

let objects : [Superclass] = [sc1, sc2, sc3]

for subclassObject in objects {
switch subclassObject {
case let object = subclassObject as? Subclass1:
doSomethingWith(object)
case let object = subclassObject as? Subclass2:
doSomethingWith(object)
case let object = subclassObject as? Subclass3:
doSomethingWith(object)
default:
return
}
}
This gives an error, expecting a colon (:) after object on every case.

I wanted to be sure I wasn't missing something in my syntax (nor some
obvious-to-others reason this isn't supported) before going to swift
evolution.


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

Re: [swift-users] @noescape

[Nate Birkholz via swift-users]

Well that was where I was going next, heh.

On Mon, May 16, 2016 at 9:41 AM, Jens Alfke <j...@mooseyard.com> wrote:

>
> On May 16, 2016, at 9:37 AM, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
> I understand how @noescape works, and some of its benefits, I *think*, but
> if I am correct, it almost seems like it should be added automatically to
> my closure definitions until it becomes clear that the closure has to
> escape its context, much like I tend to declare variables as `let` until it
> becomes clear I need a `var`.
>
>
> IIRC, there is a current proposal to change the language in exactly that
> way — i.e. to have noescape be the default and use an attribute like
> “@escapes” to declare that a closure can be stored by the callee and called
> later.
>
> —Jens
>



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

Re: [swift-users] Stored Property, Externally Read-Only

[Nate Birkholz via swift-users]

That's correct.

On Fri, Apr 29, 2016 at 8:52 AM, David Sweeris via swift-users <
swift-users@swift.org> wrote:

> Yep, declare it like this:
> public private(set) var lastUpdated: NSDate?
>
> At least I’m pretty sure that’s the syntax. I don’t have Xcode in front of
> me to double-check.
>
> HTH
> - Dave Sweeris
>
> On Apr 29, 2016, at 9:52 AM, Bob Davidson via swift-users <
> swift-users@swift.org> wrote:
>
> Hello,
>
> Does Swift have a syntax for allowing a stored property to be internally
> changed by a class/structure, but external access is read-only?
>
> For example, my class/structure may have a date property such as
> “lastUpdated”.  Outside code should have access to read the “lastUpdated”
> property, but should not be allowed to change it.  Periodically, my class
> may perform an “update” and would internally change the value of
> “lastUpdated”.
>
> The only way I see to support this with a private property and a computed,
> get-only property:
>
> private var internalLastUpdated: NSDate?
> var lastUpdated: NSDate? { return internalLastUpdated }
>
> This there a better way?
>
> Thanks,
> Bob Davidson
>
> ___
> 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
>
>


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

Re: [swift-users] FlatMap and Casting

[Nate Birkholz via swift-users]

I would swear I had marked the optional initially with the same result, but
it works, so apparently I didn't!

On Thu, Apr 21, 2016 at 1:49 PM, Dennis Weissmann <den...@dennisweissmann.me
> wrote:

> Since sublayers are optional you’re calling the the flatMap function on
> Optionals, which behaves differently.
>
> let layers = myView.layer.sublayers?.flatMap({ $0 as? CAShapeLayer }) //
> sublayers?. instead of sublayers.
>
> should fix the problem :)
>
> - Dennis
>
> On Apr 21, 2016, at 9:53 PM, Nate Birkholz via swift-users <
> swift-users@swift.org> wrote:
>
> myView.layer.sublayers returns an array of CALayer objects. Some of my
> sublayers are CAShapeLayers. I want to act on the CAShapeLayer objects.
>
> Shouldn't flatMap allow me to conditionally cast CALayers to
> CAShapeLayers? i.e.
>
> let layers = myView.layer.sublayers.flatMap({ $0 as? CAShapeLayer })
>
> The compiler warns "Cast from '[CALayer]' to unrelated type 'CAShapeLayer'
> always fails"
>
> So it looks like $0 is the array itself.
>
> This works:
>
> let layers = myView.layer.sublayers?.filter({ $0 is CAShapeLayer }).map({
> $0 as? CAShapeLayer })
>
>
> But I thought FlatMap should do it in a single step.
>
> --
> Nate Birkholz
> ___
> swift-users mailing list
> swift-users@swift.org
> https://lists.swift.org/mailman/listinfo/swift-users
>
>
>


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