Expression too complex

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
    let s=sin(a/2.0)
    let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
    let l=v.length()
    self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

···

On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
   let s=sin(a/2.0)
   let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
   let l=v.length()
   self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

I’ve seen that this tends to happen with operators that are really
overloaded-stuff like +, *, etc. The compiler seems to take longer to
figure out which function to use.

···

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users < swift-users@swift.org> wrote:

> On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> > wrote:
>
> Is progress being made on the type checker to get the compiler to stop
whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a
try in a nightly build. Please file a bug if you continue to see this in
Swift 3 though.

-Joe

>
> I can’t really trim down the full project to isolate a good test case,
but I’m getting a compiler error on this line of code:
> let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
>
>
> Interestingly, this line compiled fine (everything is the same except
the last list element is moved to the front):
> let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])
>
>
>
> The initializer that this code is embedded in is this:
> public init(axis:T.Vector3Type, angle a:T){
> let s=sin(a/2.0)
> let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
> let l=v.length()
> self.init(v/l)
> }
>
> I’m running this in a playground, I don’t know if that makes a
difference.
>
> I’m willing to wait a little longer for the complier to do its job if it
means I don’t have to break my code down to one operation per line.
> _______________________________________________
> 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

--
-Saagar Jha

I’ve seen that this tends to happen with operators that are really overloaded-stuff like +, *, etc. The compiler seems to take longer to figure out which function to use.

Yeah. The type checker has gotten better about making these situations with lots of overload operators tractable in common cases. Over the remaining course of Swift 3, we're also looking to rearchitect the standard library so that there are fewer generic global operator overloads, moving the polymorphism into protocol methods instead, which should further reduce the burden on the type checker.

-Joe

···

On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users <swift-users@swift.org> wrote:

> On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:
>
> Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

>
> I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
> let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
>
>
> Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
> let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])
>
>
>
> The initializer that this code is embedded in is this:
> public init(axis:T.Vector3Type, angle a:T){
> let s=sin(a/2.0)
> let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
> let l=v.length()
> self.init(v/l)
> }
>
> I’m running this in a playground, I don’t know if that makes a difference.
>
> I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
> _______________________________________________
> 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
--
-Saagar Jha

That could be part of it, in my case. I also have a few protocols and generics sprinkled in to generalize my type across Float and Double (something that I see Swift 3 is improving) and to use the simd types (something that I think still needs work).

Now that you mention the standard library functions, I do have this in my code which could be contributing to the pain in that initializer:

//////////////
public protocol ScalarMathType : FloatingPointMathType {
    func sin() -> Self
    func cos() -> Self
}

public func sin<T:ScalarMathType> (x:T) -> T {return x.sin()}
public func cos<T:ScalarMathType> (x:T) -> T {return x.cos()}

extension Float : ScalarMathType {
    public func sin() -> Float {return Foundation.sin(self)}
    public func cos() -> Float {return Foundation.cos(self)}
}

extension Double : ScalarMathType {
    public func sin() -> Double {return Foundation.sin(self)}
    public func cos() -> Double {return Foundation.cos(self)}
}
/////////////////

It was the best way I could find (hat tip to StackOverflow) to make the code work with with Float or Double.

···

On Jun 6, 2016, at 15:15 , Joe Groff <jgroff@apple.com> wrote:

On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

I’ve seen that this tends to happen with operators that are really overloaded-stuff like +, *, etc. The compiler seems to take longer to figure out which function to use.

Yeah. The type checker has gotten better about making these situations with lots of overload operators tractable in common cases. Over the remaining course of Swift 3, we're also looking to rearchitect the standard library so that there are fewer generic global operator overloads, moving the polymorphism into protocol methods instead, which should further reduce the burden on the type checker.

-Joe

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
  let s=sin(a/2.0)
  let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
  let l=v.length()
  self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
_______________________________________________
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
--
-Saagar Jha

I've seen this happen specifically in collections.

There was one only yesterday that I was helping out with:


Try doing this with all the String:Closure pairs in the original declaration.

-- E

···

On Jun 6, 2016, at 4:15 PM, Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

I’ve seen that this tends to happen with operators that are really overloaded-stuff like +, *, etc. The compiler seems to take longer to figure out which function to use.

Yeah. The type checker has gotten better about making these situations with lots of overload operators tractable in common cases. Over the remaining course of Swift 3, we're also looking to rearchitect the standard library so that there are fewer generic global operator overloads, moving the polymorphism into protocol methods instead, which should further reduce the burden on the type checker.

-Joe

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
  let s=sin(a/2.0)
  let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
  let l=v.length()
  self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
_______________________________________________
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
--
-Saagar Jha

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

Joe,

I had an expression that worked fine with Swift2.2 but Swift3 (Xcode 8 version) complains it's too complex:

The variables are of type CGPoint and the function returns a Bool.

    return (pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x) < 0.0

Thanks,
Dave

···

On Jun 6, 2016, at 6:15 PM, Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

I’ve seen that this tends to happen with operators that are really overloaded-stuff like +, *, etc. The compiler seems to take longer to figure out which function to use.

Yeah. The type checker has gotten better about making these situations with lots of overload operators tractable in common cases. Over the remaining course of Swift 3, we're also looking to rearchitect the standard library so that there are fewer generic global operator overloads, moving the polymorphism into protocol methods instead, which should further reduce the burden on the type checker.

-Joe

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
  let s=sin(a/2.0)
  let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
  let l=v.length()
  self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
_______________________________________________
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
--
-Saagar Jha

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

func foo () -> Bool {
    return Double((pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x)) < 0.0
}

See if that works and then file a bug report?

-- E

···

On Jun 16, 2016, at 2:59 PM, Dave Reed via swift-users <swift-users@swift.org> wrote:

Joe,

I had an expression that worked fine with Swift2.2 but Swift3 (Xcode 8 version) complains it's too complex:

The variables are of type CGPoint and the function returns a Bool.

   return (pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x) < 0.0

Thanks,
Dave

On Jun 6, 2016, at 6:15 PM, Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

I’ve seen that this tends to happen with operators that are really overloaded-stuff like +, *, etc. The compiler seems to take longer to figure out which function to use.

Yeah. The type checker has gotten better about making these situations with lots of overload operators tractable in common cases. Over the remaining course of Swift 3, we're also looking to rearchitect the standard library so that there are fewer generic global operator overloads, moving the polymorphism into protocol methods instead, which should further reduce the burden on the type checker.

-Joe

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
let s=sin(a/2.0)
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
let l=v.length()
self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
_______________________________________________
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
--
-Saagar Jha

_______________________________________________
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

Thanks for letting us know. If you haven't yet, would you have time to file a bug report? cc'ing Joe Pamer in case he has any ideas here.

-Joe

···

On Jun 16, 2016, at 1:59 PM, davelist@mac.com wrote:

Joe,

I had an expression that worked fine with Swift2.2 but Swift3 (Xcode 8 version) complains it's too complex:

The variables are of type CGPoint and the function returns a Bool.

   return (pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x) < 0.0

Yes, Erica, your version works. I had just split it up into:

   let temp1 = (pt.x - p0.x) * (p1.y - p0.y)
   let temp2 = (pt.y - p0.y) * (p1.x - p0.x)
   return (temp1 - temp2) < 0.0

which also works.

Filed: SR-1794

Is that where I should also file the CGContext endPage() method not working (I filed it at bugreport.apple.com)?

Thanks,
Dave Reed

···

On Jun 16, 2016, at 5:20 PM, Erica Sadun <erica@ericasadun.com> wrote:

func foo () -> Bool {
    return Double((pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x)) < 0.0
}

See if that works and then file a bug report?

-- E

On Jun 16, 2016, at 2:59 PM, Dave Reed via swift-users <swift-users@swift.org> wrote:

Joe,

I had an expression that worked fine with Swift2.2 but Swift3 (Xcode 8 version) complains it's too complex:

The variables are of type CGPoint and the function returns a Bool.

   return (pt.x - p0.x) * (p1.y - p0.y) - (pt.y - p0.y) * (p1.x - p0.x) < 0.0

Thanks,
Dave

On Jun 6, 2016, at 6:15 PM, Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28@gmail.com> wrote:

I’ve seen that this tends to happen with operators that are really overloaded-stuff like +, *, etc. The compiler seems to take longer to figure out which function to use.

Yeah. The type checker has gotten better about making these situations with lots of overload operators tractable in common cases. Over the remaining course of Swift 3, we're also looking to rearchitect the standard library so that there are fewer generic global operator overloads, moving the polymorphism into protocol methods instead, which should further reduce the burden on the type checker.

-Joe

On Mon, Jun 6, 2016 at 3:09 PM Joe Groff via swift-users <swift-users@swift.org> wrote:

On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users@swift.org> wrote:

Is progress being made on the type checker to get the compiler to stop whinging about the complexity of expressions?

Yes, a lot of cases work much better in Swift 3. You might give these a try in a nightly build. Please file a bug if you continue to see this in Swift 3 though.

-Joe

I can’t really trim down the full project to isolate a good test case, but I’m getting a compiler error on this line of code:
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])

Interestingly, this line compiled fine (everything is the same except the last list element is moved to the front):
let v=T.Vector4Type([cos(a/2.0), axis[0]*s, axis[1]*s, axis[2]*s])

The initializer that this code is embedded in is this:
public init(axis:T.Vector3Type, angle a:T){
let s=sin(a/2.0)
let v=T.Vector4Type([axis[0]*s, axis[1]*s, axis[2]*s, cos(a/2.0)])
let l=v.length()
self.init(v/l)
}

I’m running this in a playground, I don’t know if that makes a difference.

I’m willing to wait a little longer for the complier to do its job if it means I don’t have to break my code down to one operation per line.
_______________________________________________
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
--
-Saagar Jha

_______________________________________________
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

I was asked to try out the latest betas of Cocoa to check if a SceneKit bug I reported has been fixed. As part of this I decided to try an update to Swift 3. I've run into a number of minor issues, but one has me frustrated. In my menu validate method, I have:

    switch menuItem.action {
      case #selector!(showRescale) :

This worked fine in 2.2, but now it complains that it expects a ( after #selector. Removing the ! fixes that problem, but now returns an error that there's a missing !, which it inserts to cause the original error again. I also tried placing it after the ()'s, and now it complains that it's expecting the :

Does anyone know the proper Swift 3 syntax for this?

I was asked to try out the latest betas of Cocoa to check if a SceneKit bug I reported has been fixed. As part of this I decided to try an update to Swift 3. I've run into a number of minor issues, but one has me frustrated. In my menu validate method, I have:

    switch menuItem.action {
      case #selector!(showRescale) :

This worked fine in 2.2, but now it complains that it expects a ( after #selector. Removing the ! fixes that problem, but now returns an error that there's a missing !, which it inserts to cause the original error again. I also tried placing it after the ()'s, and now it complains that it's expecting the :

Does anyone know the proper Swift 3 syntax for this?

tl;dr: Write this instead:

  case #selector(showRescale)?:

The explanation:

In Swift 2, Selectors could *always* be nil, even when they weren't optional. The same was true of UnsafePointer and a few other types, and it wasn't great. So in Swift 3, we've changed these types so they now can only be nil if they're optional.

Because of this change, the type of `NSMenuItem.action` changed from `Selector` to `Selector?`. That means the patterns in your `switch` statement need to look like:

  case Optional.some(#selector(showRescale)):

Which you can specify in a pattern match (like a case statement) using the convenient trailing-question-mark syntax I showed above:

  case #selector(showRescale)?:

The Swift 3 migrator should have generated this code, so you've probably encountered a bug. It would help them if you could create a small example project and file a bug report at <Feedback Assistant. (The migrator is closed source.)

Hope this helps,

···

--
Brent Royal-Gordon
Architechies

Can you give more information on the function showRescale, is it function
showRescale() or showRescale(a:foo)?
Or have you tried case let x where x == #selector(showRescale):

Zhaoxin

···

On Fri, Jun 17, 2016 at 9:33 PM, Maury Markowitz via swift-users < swift-users@swift.org> wrote:

I was asked to try out the latest betas of Cocoa to check if a SceneKit
bug I reported has been fixed. As part of this I decided to try an update
to Swift 3. I've run into a number of minor issues, but one has me
frustrated. In my menu validate method, I have:

                switch menuItem.action {
                        case #selector!(showRescale) :

This worked fine in 2.2, but now it complains that it expects a ( after
#selector. Removing the ! fixes that problem, but now returns an error that
there's a missing !, which it inserts to cause the original error again. I
also tried placing it after the ()'s, and now it complains that it's
expecting the :

Does anyone know the proper Swift 3 syntax for this?
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

This code snippet works for me in a menu validation function...

        guard let action = anItem?.action else { return false }
        switch action {
        case #selector(showOpenPanel(_:)):
            return true
        case #selector(save(_:)):
            return modified
        case #selector(openPreferencesWindow(_:)):
            return true
        default:
            print("default for item \(anItem)")
        }
        return false

I used the guard let... to get around the fact that action selectors are now optionals.

···

On Fri, Jun 17, 2016 at 9:33 PM, Maury Markowitz via swift-users <swift-users@swift.org> wrote:
I was asked to try out the latest betas of Cocoa to check if a SceneKit bug I reported has been fixed. As part of this I decided to try an update to Swift 3. I've run into a number of minor issues, but one has me frustrated. In my menu validate method, I have:

                switch menuItem.action {
                        case #selector!(showRescale) :

This worked fine in 2.2, but now it complains that it expects a ( after #selector. Removing the ! fixes that problem, but now returns an error that there's a missing !, which it inserts to cause the original error again. I also tried placing it after the ()'s, and now it complains that it's expecting the :

Does anyone know the proper Swift 3 syntax for this?

Tried that too, it causes another error:

    /Developer/SwiftNEC 3/SwiftNEC/CardViews.swift:139:28: Expected ':' after 'case'

Here are the formats I have tried; all fail with various errors:

    case #selector(showRescale):
    case #selector(showRescale)?:
    case #selector(showRescale)? :
    case #selector(showRescale)!:
    case #selector(showRescale)! :
    case #selector!(showRescale):
    case #selector!(showRescale) :

This format, however, did work:

    case Optional.some(#selector(showRescale)):

Optional.some? Urk.

···

On Jun 17, 2016, at 1:31 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
tl;dr: Write this instead:

  case #selector(showRescale)?:

Tried that too, it causes another error:

   /Developer/SwiftNEC 3/SwiftNEC/CardViews.swift:139:28: Expected ':' after 'case'

Huh, that's really strange. This syntax, which should be equivalent, causes a compiler crash:

  case (#selector(showRescale))?:

So does the slightly-more-shorthanded version:

  case .some(#selector(showRescale)):

I'd file another bug about this, this time in the Swift open-source bug tracker at <https://bugs.swift.org>.

···

--
Brent Royal-Gordon
Architechies

I had a bit of problem getting #selector working with swift 3 I eventual got it to work with your second to last line I think, I've had a couple of problems with errors that I can't fix, type casting mainly, I have often found fixing other errors, even if they come after will make the initial error go away, I have passed it of as beta problems, I still have finished so I don't know if all my problems can be fixed like this.

···

Sent from my iPhone

On 18 Jun 2016, at 7:48 AM, Maury Markowitz via swift-users <swift-users@swift.org> wrote:

On Jun 17, 2016, at 1:31 PM, Brent Royal-Gordon <brent@architechies.com> wrote:
tl;dr: Write this instead:

   case #selector(showRescale)?:

Tried that too, it causes another error:

   /Developer/SwiftNEC 3/SwiftNEC/CardViews.swift:139:28: Expected ':' after 'case'

Here are the formats I have tried; all fail with various errors:

   case #selector(showRescale):
   case #selector(showRescale)?:
   case #selector(showRescale)? :
   case #selector(showRescale)!:
   case #selector(showRescale)! :
   case #selector!(showRescale):
   case #selector!(showRescale) :

This format, however, did work:

   case Optional.some(#selector(showRescale)):

Optional.some? Urk.
_______________________________________________
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

It seems, that the new Xcode 9.3 again has difficulties in interpreting expressions like that: "Expression was too complex..."

result.kurtosis = (3.0 * (a + b + 1.0) * (pow(a, 2.0) * (b + 2) + pow(b, 2.0) * (a + 2.0) - 2.0 * a * b)) / (a * b * (a + b + 2.0) * (a + b + 3.0))

Using Xcode 9.2 that expression works fine...

Yeah, Xcode 9.3 suddenly finds this too complex as well:
let str = (components.year ?? 0) * 10000 + (components.month ?? 0) * 100 + (components.day ?? 0)

Worked fine before.

Yeah, Xcode 9.3 suddenly finds this too complex as well:
let str = (components.year ?? 0) * 10000 + (components.month ?? 0) * 100 + (components.day ?? 0)

Worked fine before.

With all due respect! That's ridiculous. The situation gets worse from update to update.