> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> This could work, but you’re also giving up all the nice Numeric and
>> FloatingPoint conformances when you use this,, all of a sudden adding two
>> angles together isn’t let γ = α + β, it’s γ = Angle.radians(α.radians +
>> β.radians). just no. at the risk of blowing up the scope of this idea,
>> dedicated Angle types also begs for generic trigonometric functions like
>> Angle.sin(_:) and Angle.cos(_:). i proposed that a while back and even tried
>> implementing it but fast trig evaluation doesn’t genericize well since it
>> relies a lot on rsqrt-style magic constants
>
> You could add those conformances back, if you wanted. Most low-level trig
> code will quickly escape the wrapper once it starts using the values. Mostly
> I use it as a currency type and for converting untyped angles. I think it’s a
> great example of Swift’s zero-cost abstractions - we added semantic meaning
> (this value isn’t just a number with a specific bit representation, it’s a
> number which represents a specific kind of quantity), and encapsulated some
> useful functionality, and we don't lose any performance.
And in fact you probably don’t want that conformance. It makes sense
dimensionally to add two angles. It doesn’t (generally) make as much sense to
multiply them, or to take the square root of an angle. I would expect an angle
type to provide + and - but probably not * and / and most of the other
floating-point operations.
– Steve
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
