Re: [swift-users] expression too complex

[Joe Groff via swift-users]

> On Jun 16, 2016, at 1:59 PM, davel...@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

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
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users

Re: [swift-users] expression too complex

[Dave Reed via swift-users]

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  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 
>>  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 
>>>  wrote:
>>> 
>>> 
 On Jun 6, 2016, at 3:13 PM, Saagar Jha  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 
  wrote:
 
> On Jun 6, 2016, at 3:06 PM, G B via swift-users  
> 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
> 

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

Re: [swift-users] expression too complex

[Erica Sadun via 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 
>  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 
>>  wrote:
>> 
>> 
>>> On Jun 6, 2016, at 3:13 PM, Saagar Jha  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 
>>>  wrote:
>>> 
 On Jun 6, 2016, at 3:06 PM, G B via swift-users  
 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

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

Re: [swift-users] expression too complex

[G B via swift-users]

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 (x:T) -> T {return x.sin()}
public func cos (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  wrote:
> 
> 
>> On Jun 6, 2016, at 3:13 PM, Saagar Jha  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 
>>  wrote:
>> 
>>> On Jun 6, 2016, at 3:06 PM, G B via swift-users  
>>> 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

Re: [swift-users] expression too complex

[Erica Sadun via swift-users]

I've seen this happen specifically in collections.

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

http://i.imgur.com/tKh9On6.jpg 

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  
> wrote:
> 
> 
>> On Jun 6, 2016, at 3:13 PM, Saagar Jha  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 
>>  wrote:
>> 
>>> On Jun 6, 2016, at 3:06 PM, G B via swift-users  
>>> 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

Re: [swift-users] expression too complex

[Saagar Jha via 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 
> 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

Re: [swift-users] expression too complex

[Joe Groff via swift-users]

> On Jun 6, 2016, at 3:06 PM, G B via swift-users  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

[swift-users] expression too complex

[G B via swift-users]

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.
___
swift-users mailing list
swift-users@swift.org
https://lists.swift.org/mailman/listinfo/swift-users