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 <jgr...@apple.com> wrote:
>
>
>> On Jun 6, 2016, at 3:13 PM, Saagar Jha <saagarjh...@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
