> On Jan 15, 2018, at 3:40 PM, Stephen Canon <sca...@apple.com> wrote:
>
>
>
>>> 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> 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
steradians?
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
