[swift-users] expression too complex

[G B]

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 at apple.com> wrote:
> 
> 
>> On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjha28 at 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 at swift.org> wrote:
>> 
>>> On Jun 6, 2016, at 3:06 PM, G B via swift-users <swift-users at 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 at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-users
>> 
>> _______________________________________________
>> swift-users mailing list
>> swift-users at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-users
>> -- 
>> -Saagar Jha
>