Prefer CGFloat.pi to CGFloat(M_PI)

[ghost]

Swift supports CGFloat.pi for a CGFloat version of π as opposed to a Double. It also appears that M_PI is being deprecated.

It would be good in the obvious cases where the developer wants a CGFloat version of π to detect and autocorrect to use the new Swift-y constant, avoid the typecast, and make the code more readable.

This may make sense as an extension of legacy_constant?

For reference:

• Deprecating M_PI and a few other constants in favor of better API swiftlang/swift#6764
• [stdlib] Replacing M_PI with .pi swiftlang/swift#6802

[marcelofabri]

This may make sense as an extension of legacy_constant?

Makes sense for me!

[ghost]

Hmmm... this may be better off in a separate rule. 🤔

The CGFloat.pi (and Float.pi) are only available in Swift 3+.

Also CGFloat(M_PI) results in two identifiers from SourceKitten, not one. So it's a different matching pattern than all of the rest of the legacy constants.

[marcelofabri]

I think semantically it makes more sense to be the same rule, even if the implementation is a bit different.

You can use SwiftVersion.current to switch on the Swift version.

[stephentyrone]

It's worth noting that CGFloat(M_PI) is very subtly different from CGFloat.pi on platforms where CGFloat is an alias of Float. Float.pi is 0x1.921fb4p1, but Float(Double.pi) is 0x1.921fb6p1. This is deliberate; π rounded to the nearest Float rounds up, outside the interval [0,π], which sometimes results in subtle bugs. So this change is more likely to fix bugs than cause them, but it's still something to be aware of.

[ghost]

@marcelofabri Sounds good. I'll continue down my the path of my initial implementation. I should have a PR raised later today.

[raid5]

This appears to have introduced a bug where autocorrect is converting CGFloat(M_PI) to CGFloat.pi in Swift 2.3 code.

[marcelofabri]

@raid5 I couldn't reproduce it. Could you fill an issue with more details?

[raid5]

@marcelofabri, no problem. #1238