Re: [swift-evolution] [Pitch] Angle Type

[Erica Sadun via swift-evolution]

> On Jan 15, 2018, at 2:40 PM, Stephen Canon via swift-evolution 
>  wrote:
> 
> 
> 
>> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution 
>> > wrote:
>> 
>>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution 
>>> > 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

This is getting way off topic for Evolution but I'd like to point out that 
`angle * factor` and `angle / factor ` both make sense. Maybe we should take 
this conversation over to some kind of ad-hoc Swift Geometry forum?

-- E


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Angle Type

[Karl Wagner via swift-evolution]

> On 15. Jan 2018, at 23:55, Taylor Swift  wrote:
> 
> 
> 
> On Jan 15, 2018, at 3:30 PM, Karl Wagner  > wrote:
> 
>> 
>> 
>>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution 
>>> > 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.
>> 
>> I have a couple of these, such as Distance and Time (wraps a 
>> TimeInterval). This allows me to write algorithms like:
>> 
>> public func point(_ distance: Distance, along bearing: 
>> Angle) -> Geo.Point
>> 
>> And use it like this:
>> 
>> let nextPlace = thisPlace.point(.kilometers(42), along: .degrees(45))
>> 
>> Or this:
>> 
>> let nextPlace = thisPlace.point(.miles(500), along: .radians(.pi/2))
>> 
>> And so my algorithm actually becomes quite difficult to use incorrectly. 
>> Also, that’s why I use static constructors; similar to how lots of OptionSet 
>> types are implemented, doing it this way lets you use an enum-like syntax to 
>> create values, which fits Angle’s intended use as a parameter/return type.
>> 
>> I’m not saying this should be part of the standard library (this isn’t my 
>> pitch), I’m just saying these kind of wrappers are useful when creating good 
>> APIs. I think somebody was dismissing the idea of an Angle type in 
>> general before.
>> 
>> - Karl
> 
> i thought the whole thing with resiliency barriers is that these kinds of 
> abstractions are *not* zero cost anymore, accessing a member of an imported 
> struct is always going to be through an indirect getter and setter. && this 
> doesn’t get fixed by slava’s inlineable thing because you can’t “inline” a 
> struct layout

This is what the @fixed_layout (or @frozen, or whatever it ends up being 
called) attribute is for. Resilience means that we have built-in indirection to 
allow for library evolution, but the design is that you can opt-out of that 
indirection and expose cross-module inlining or other optimisation 
opportunities.

https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#fixed-contents-structs

- Karl

> 
>> 
>>> 
>>> also, why are radians(_:) and degrees(_:) static functions? i really only 
>>> use static constructors for initializers that have side effects
>>> 
>>> On Sun, Jan 14, 2018 at 6:36 AM, Karl Wagner >> > wrote:
>>> 
>>> 
 On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution 
 > wrote:
 
 I do a lot of geometry and spherical-related work and i have never found 
 an Angle type to be worth having. Always use radians. It’s what sin() and 
 cos() take, it’s what graphics APIs like Cairo expect, it’s what graphics 
 formats like SVG use. plus,, do you *really* want to be case-branching on 
 every angle value? that really adds up when you’re converting 100,000s of 
 lat-long pairs to cartesian.
>>> 
>>> You can do it without case-branching. I too have an Angle type; this is 
>>> what I use:
>>> 
>>> public struct Angle {
>>>   public var radians: T
>>>   public var degrees: T {
>>> return (radians / .pi) * 180
>>>   }
>>> 
>>>   public static func radians(_ rads: T) -> Angle {
>>> return Angle(radians: rads)
>>>   }
>>>   public static func degrees(_ degs: T) -> Angle {
>>> return Angle(radians: (degs / 180) * .pi)
>>>   }
>>> }
>>> 
>>> If you ask for “radians” (like most low-level trig code will), you just get 
>>> the stored property. The conversion “overhead” is only done at construction 
>>> time, so it makes a convenient parameter/return value.
>>> 
>>> - Karl
>>> 
 
 On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
 > wrote:
 
> An Angle type already exists in 

Re: [swift-evolution] [Pitch] Angle Type

[Taylor Swift via swift-evolution]

> On Jan 15, 2018, at 3:40 PM, Stephen Canon  wrote:
> 
> 
> 
>>> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution 
>>>  wrote:
>>> 
>>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution 
>>>  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

Re: [swift-evolution] [Pitch] Angle Type

[Taylor Swift via swift-evolution]

> On Jan 15, 2018, at 3:30 PM, Karl Wagner  wrote:
> 
> 
> 
>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution 
>>  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.
> 
> I have a couple of these, such as Distance and Time (wraps a 
> TimeInterval). This allows me to write algorithms like:
> 
> public func point(_ distance: Distance, along bearing: 
> Angle) -> Geo.Point
> 
> And use it like this:
> 
> let nextPlace = thisPlace.point(.kilometers(42), along: .degrees(45))
> 
> Or this:
> 
> let nextPlace = thisPlace.point(.miles(500), along: .radians(.pi/2))
> 
> And so my algorithm actually becomes quite difficult to use incorrectly. 
> Also, that’s why I use static constructors; similar to how lots of OptionSet 
> types are implemented, doing it this way lets you use an enum-like syntax to 
> create values, which fits Angle’s intended use as a parameter/return type.
> 
> I’m not saying this should be part of the standard library (this isn’t my 
> pitch), I’m just saying these kind of wrappers are useful when creating good 
> APIs. I think somebody was dismissing the idea of an Angle type in general 
> before.
> 
> - Karl

i thought the whole thing with resiliency barriers is that these kinds of 
abstractions are *not* zero cost anymore, accessing a member of an imported 
struct is always going to be through an indirect getter and setter. && this 
doesn’t get fixed by slava’s inlineable thing because you can’t “inline” a 
struct layout

> 
>> 
>> also, why are radians(_:) and degrees(_:) static functions? i really only 
>> use static constructors for initializers that have side effects
>> 
>>> On Sun, Jan 14, 2018 at 6:36 AM, Karl Wagner  wrote:
>>> 
>>> 
 On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution 
  wrote:
 
 I do a lot of geometry and spherical-related work and i have never found 
 an Angle type to be worth having. Always use radians. It’s what sin() and 
 cos() take, it’s what graphics APIs like Cairo expect, it’s what graphics 
 formats like SVG use. plus,, do you *really* want to be case-branching on 
 every angle value? that really adds up when you’re converting 100,000s of 
 lat-long pairs to cartesian.
>>> 
>>> You can do it without case-branching. I too have an Angle type; this is 
>>> what I use:
>>> 
>>> public struct Angle {
>>>   public var radians: T
>>>   public var degrees: T {
>>> return (radians / .pi) * 180
>>>   }
>>> 
>>>   public static func radians(_ rads: T) -> Angle {
>>> return Angle(radians: rads)
>>>   }
>>>   public static func degrees(_ degs: T) -> Angle {
>>> return Angle(radians: (degs / 180) * .pi)
>>>   }
>>> }
>>> 
>>> If you ask for “radians” (like most low-level trig code will), you just get 
>>> the stored property. The conversion “overhead” is only done at construction 
>>> time, so it makes a convenient parameter/return value.
>>> 
>>> - Karl
>>> 
 
> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
>  wrote:
> 
> An Angle type already exists in Foundation; see Measurement. 
> You could add some convenience methods in an extension pretty easily.
> 
> import Foundation
> 
> typealias Angle = Measurement
> 
> extension Measurement where UnitType == UnitAngle {
> var sine: Double {
> let radians = self.converted(to: .radians).value
> return sin(radians)
> }
> 
> static var threeQuarterTurn: Angle {
> return Angle(value: 0.75, unit: .revolutions)
> }
> }
> 
> let x = Angle.threeQuarterTurn
> x.sine // -1
> 
> -BJ
> 
> 
>> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 

Re: [swift-evolution] [Pitch] Angle Type

[Stephen Canon via swift-evolution]

> On Jan 15, 2018, at 4:31 PM, Karl Wagner via swift-evolution 
>  wrote:
> 
>> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution 
>> > 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

Re: [swift-evolution] [Pitch] Angle Type

[Karl Wagner via swift-evolution]

> On 14. Jan 2018, at 21:12, Kelvin Ma via swift-evolution 
>  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.

I have a couple of these, such as Distance and Time (wraps a TimeInterval). 
This allows me to write algorithms like:

public func point(_ distance: Distance, along bearing: 
Angle) -> Geo.Point

And use it like this:

let nextPlace = thisPlace.point(.kilometers(42), along: .degrees(45))

Or this:

let nextPlace = thisPlace.point(.miles(500), along: .radians(.pi/2))

And so my algorithm actually becomes quite difficult to use incorrectly. Also, 
that’s why I use static constructors; similar to how lots of OptionSet types 
are implemented, doing it this way lets you use an enum-like syntax to create 
values, which fits Angle’s intended use as a parameter/return type.

I’m not saying this should be part of the standard library (this isn’t my 
pitch), I’m just saying these kind of wrappers are useful when creating good 
APIs. I think somebody was dismissing the idea of an Angle type in general 
before.

- Karl

> 
> also, why are radians(_:) and degrees(_:) static functions? i really only use 
> static constructors for initializers that have side effects
> 
> On Sun, Jan 14, 2018 at 6:36 AM, Karl Wagner  > wrote:
> 
> 
>> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution 
>> > wrote:
>> 
>> I do a lot of geometry and spherical-related work and i have never found an 
>> Angle type to be worth having. Always use radians. It’s what sin() and cos() 
>> take, it’s what graphics APIs like Cairo expect, it’s what graphics formats 
>> like SVG use. plus,, do you *really* want to be case-branching on every 
>> angle value? that really adds up when you’re converting 100,000s of lat-long 
>> pairs to cartesian.
> 
> You can do it without case-branching. I too have an Angle type; this is what 
> I use:
> 
> public struct Angle {
>   public var radians: T
>   public var degrees: T {
> return (radians / .pi) * 180
>   }
> 
>   public static func radians(_ rads: T) -> Angle {
> return Angle(radians: rads)
>   }
>   public static func degrees(_ degs: T) -> Angle {
> return Angle(radians: (degs / 180) * .pi)
>   }
> }
> 
> If you ask for “radians” (like most low-level trig code will), you just get 
> the stored property. The conversion “overhead” is only done at construction 
> time, so it makes a convenient parameter/return value.
> 
> - Karl
> 
>> 
>> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
>> > wrote:
>> 
>>> An Angle type already exists in Foundation; see Measurement. You 
>>> could add some convenience methods in an extension pretty easily.
>>> 
>>> import Foundation
>>> 
>>> typealias Angle = Measurement
>>> 
>>> extension Measurement where UnitType == UnitAngle {
>>> var sine: Double {
>>> let radians = self.converted(to: .radians).value
>>> return sin(radians)
>>> }
>>> 
>>> static var threeQuarterTurn: Angle {
>>> return Angle(value: 0.75, unit: .revolutions)
>>> }
>>> }
>>> 
>>> let x = Angle.threeQuarterTurn
>>> x.sine // -1
>>> 
>>> -BJ
>>> 
>>> 
 On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution 
 > wrote:
 
 I would like to see a full Geometry implementation but I don't think it 
 should be part of the standard library.
 
 I've kicked around some ideas here: 
 
 * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b 
 
 * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721 
 
 
 and
 
 * 

Re: [swift-evolution] [Pitch] Angle Type

[Kelvin Ma via swift-evolution]

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

also, why are radians(_:) and degrees(_:) static functions? i really only
use static constructors for initializers that have side effects

On Sun, Jan 14, 2018 at 6:36 AM, Karl Wagner  wrote:

>
>
> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I do a lot of geometry and spherical-related work and i have never found
> an Angle type to be worth having. Always use radians. It’s what sin() and
> cos() take, it’s what graphics APIs like Cairo expect, it’s what graphics
> formats like SVG use. plus,, do you *really* want to be case-branching on
> every angle value? that really adds up when you’re converting 100,000s of
> lat-long pairs to cartesian.
>
>
> You can do it without case-branching. I too have an Angle type; this is
> what I use:
>
> public struct Angle {
>   public var radians: T
>   public var degrees: T {
> return (radians / .pi) * 180
>   }
>
>   public static func radians(_ rads: T) -> Angle {
> return Angle(radians: rads)
>   }
>   public static func degrees(_ degs: T) -> Angle {
> return Angle(radians: (degs / 180) * .pi)
>   }
> }
>
> If you ask for “radians” (like most low-level trig code will), you just
> get the stored property. The conversion “overhead” is only done at
> construction time, so it makes a convenient parameter/return value.
>
> - Karl
>
>
> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> An Angle type already exists in Foundation; see Measurement.
> You could add some convenience methods in an extension pretty easily.
>
> import Foundation
>
> typealias Angle = Measurement
>
> extension Measurement where UnitType == UnitAngle {
> var sine: Double {
> let radians = self.converted(to: .radians).value
> return sin(radians)
> }
>
>
> static var threeQuarterTurn: Angle {
> return Angle(value: 0.75, unit: .revolutions)
> }
> }
>
> let x = Angle.threeQuarterTurn
> x.sine // -1
>
>
> -BJ
>
>
> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> I would like to see a full Geometry implementation but I don't think it
> should be part of the standard library.
>
> I've kicked around some ideas here:
>
> * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b
> * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721
>
> and
>
> * https://github.com/erica/SwiftGeometry
>
> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Hi Evolution,
>
> I would *really* like to see Swift gain an Angle type in the standard
> library.  Every time I have to deal with an angle in an api, I have to go
> figure out the conventions for that call.  Is it in degrees? Is it in
> radians?  What if it is in radians, but I want to think about it in degrees?
>
> I ended up writing an Angle type for my own code a few years back, and I
> have to say it is really wonderful.  It has greatly simplified my graphics
> work.  It takes a lot of mental load off of my brain when dealing with
> Angles.
>
> I can of course initialize it either as degrees or radians (or
> revolutions), but I can also just say things like ‘.threeQuarterTurn’, and
> then I can get the value back out in whatever format I like.  There are
> also useful additions that let me normalize the angle to different ranges
> and which let me snap to the nearest multiple of an angle. Both of these
> are enormously useful for user facing features.  I can also do math on
> angles in a way that makes geometric sense for angles.  It is also really
> useful for interacting with CGVectors in intelligent ways.
>
> Using Doubles or CGFloats to represent angles everywhere is just
> semantically wrong IMHO, and it stops us from adding all of these
> angle-specific niceties.
>
> Happy to provide code if there is interest…
>
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> 

Re: [swift-evolution] [Pitch] Angle Type

[Karl Wagner via swift-evolution]

> On 14. Jan 2018, at 06:04, BJ Homer via swift-evolution 
>  wrote:
> 
> An Angle type already exists in Foundation; see Measurement. You 
> could add some convenience methods in an extension pretty easily.
> 
> import Foundation
> 
> typealias Angle = Measurement
> 
> extension Measurement where UnitType == UnitAngle {
> var sine: Double {
> let radians = self.converted(to: .radians).value
> return sin(radians)
> }
> 
> static var threeQuarterTurn: Angle {
> return Angle(value: 0.75, unit: .revolutions)
> }
> }
> 
> let x = Angle.threeQuarterTurn
> x.sine // -1
> 
> -BJ

Maybe it would be good to pitch such improvements to the Foundation API? 
“Angle” is certainly a lot more discoverable and convenient to type than 
“Measurement”. That said, I tend not to use Foundation’s Measurement 
API. It’s pretty heavyweight.

test.swift:

import Foundation

@available(macOS 10.12, *)
func a() {
let a = Measurement(value: 20, unit: UnitDuration.minutes).converted(to: 
.seconds)
 }

Generated IR:

define hidden swiftcc void @_T04test1ayyF() #0 {
entry:
  %0 = call %swift.type* @_T0So12UnitDurationCMa() #3
  %1 = getelementptr inbounds %swift.type, %swift.type* %0, i32 0, i32 0
  %.kind = load i64, i64* %1, align 8
  %isObjCClassWrapper = icmp eq i64 %.kind, 14
  br i1 %isObjCClassWrapper, label %isWrapper, label %metadataForClass.cont

isWrapper:; preds = %entry
  %2 = bitcast %swift.type* %0 to %swift.type**
  %3 = getelementptr inbounds %swift.type*, %swift.type** %2, i64 1
  %4 = load %swift.type*, %swift.type** %3, align 8, !invariant.load !31
  br label %metadataForClass.cont

metadataForClass.cont:; preds = %isWrapper, %entry
  %.class = phi %swift.type* [ %0, %entry ], [ %4, %isWrapper ]
  %5 = bitcast %swift.type* %.class to %objc_class*
  %6 = load i8*, i8** @"\01L_selector(minutes)", align 8
  %7 = bitcast %objc_class* %5 to i8*
  %8 = call %0* bitcast (void ()* @objc_msgSend to %0* (i8*, i8*)*)(i8* %7, i8* 
%6)
  %9 = bitcast %0* %8 to i8*
  %10 = call i8* @objc_retainAutoreleasedReturnValue(i8* %9) #4
  %11 = bitcast i8* %10 to %0*
  %12 = bitcast %0* %11 to %TSo12UnitDurationC*
  %.asUnsubstituted = bitcast %TSo12UnitDurationC* %12 to %TSo4UnitC*
  %13 = call swiftcc { %TSo4UnitC*, double } 
@_T010Foundation11MeasurementVACyxGSd5value_x4unittcfC(double 2.00e+01, 
%TSo4UnitC* %.asUnsubstituted, %swift.type* %0)
  %14 = extractvalue { %TSo4UnitC*, double } %13, 0
  %15 = extractvalue { %TSo4UnitC*, double } %13, 1
  %.asSubstituted = bitcast %TSo4UnitC* %14 to %TSo12UnitDurationC*
  %16 = getelementptr inbounds %swift.type, %swift.type* %0, i32 0, i32 0
  %.kind1 = load i64, i64* %16, align 8
  %isObjCClassWrapper2 = icmp eq i64 %.kind1, 14
  br i1 %isObjCClassWrapper2, label %isWrapper3, label %metadataForClass.cont4

isWrapper3:   ; preds = 
%metadataForClass.cont
  %17 = bitcast %swift.type* %0 to %swift.type**
  %18 = getelementptr inbounds %swift.type*, %swift.type** %17, i64 1
  %19 = load %swift.type*, %swift.type** %18, align 8, !invariant.load !31
  br label %metadataForClass.cont4

metadataForClass.cont4:   ; preds = %isWrapper3, 
%metadataForClass.cont
  %.class5 = phi %swift.type* [ %0, %metadataForClass.cont ], [ %19, 
%isWrapper3 ]
  %20 = bitcast %swift.type* %.class5 to %objc_class*
  %21 = load i8*, i8** @"\01L_selector(seconds)", align 8
  %22 = bitcast %objc_class* %20 to i8*
  %23 = call %0* bitcast (void ()* @objc_msgSend to %0* (i8*, i8*)*)(i8* %22, 
i8* %21)
  %24 = bitcast %0* %23 to i8*
  %25 = call i8* @objc_retainAutoreleasedReturnValue(i8* %24) #4
  %26 = bitcast i8* %25 to %0*
  %27 = bitcast %0* %26 to %TSo12UnitDurationC*
  %.asUnsubstituted6 = bitcast %TSo12UnitDurationC* %27 to %TSo9DimensionC*
  %.asSubstituted.asUnsubstituted = bitcast %TSo12UnitDurationC* 
%.asSubstituted to %TSo9DimensionC*
  %28 = call swiftcc { %TSo9DimensionC*, double } 
@_T010Foundation11MeasurementVAASo9DimensionCRbzlE9convertedACyxGx2to_tF(%TSo9DimensionC*
 %.asUnsubstituted6, %TSo9DimensionC* %.asSubstituted.asUnsubstituted, double 
%15, %swift.type* %0)
  %29 = extractvalue { %TSo9DimensionC*, double } %28, 0
  %30 = extractvalue { %TSo9DimensionC*, double } %28, 1
  %.asSubstituted7 = bitcast %TSo9DimensionC* %29 to %TSo12UnitDurationC*
  call void bitcast (void (%objc_object*)* @objc_release to void 
(%TSo12UnitDurationC*)*)(%TSo12UnitDurationC* %.asSubstituted) #4
  call void bitcast (void (%objc_object*)* @objc_release to void 
(%TSo12UnitDurationC*)*)(%TSo12UnitDurationC* %.asSubstituted7) #4
  ret void
}

declare swiftcc { %TSo9DimensionC*, double } 
@_T010Foundation11MeasurementVAASo9DimensionCRbzlE9convertedACyxGx2to_tF(%TSo9DimensionC*,
 %TSo9DimensionC*, double, %swift.type*) #0

declare swiftcc { %TSo4UnitC*, double } 

Re: [swift-evolution] [Pitch] Angle Type

[Karl Wagner via swift-evolution]

> On 14. Jan 2018, at 09:51, Taylor Swift via swift-evolution 
>  wrote:
> 
> I do a lot of geometry and spherical-related work and i have never found an 
> Angle type to be worth having. Always use radians. It’s what sin() and cos() 
> take, it’s what graphics APIs like Cairo expect, it’s what graphics formats 
> like SVG use. plus,, do you *really* want to be case-branching on every angle 
> value? that really adds up when you’re converting 100,000s of lat-long pairs 
> to cartesian.

You can do it without case-branching. I too have an Angle type; this is what I 
use:

public struct Angle {
  public var radians: T
  public var degrees: T {
return (radians / .pi) * 180
  }

  public static func radians(_ rads: T) -> Angle {
return Angle(radians: rads)
  }
  public static func degrees(_ degs: T) -> Angle {
return Angle(radians: (degs / 180) * .pi)
  }
}

If you ask for “radians” (like most low-level trig code will), you just get the 
stored property. The conversion “overhead” is only done at construction time, 
so it makes a convenient parameter/return value.

- Karl

> 
> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
> > wrote:
> 
>> An Angle type already exists in Foundation; see Measurement. You 
>> could add some convenience methods in an extension pretty easily.
>> 
>> import Foundation
>> 
>> typealias Angle = Measurement
>> 
>> extension Measurement where UnitType == UnitAngle {
>> var sine: Double {
>> let radians = self.converted(to: .radians).value
>> return sin(radians)
>> }
>> 
>> static var threeQuarterTurn: Angle {
>> return Angle(value: 0.75, unit: .revolutions)
>> }
>> }
>> 
>> let x = Angle.threeQuarterTurn
>> x.sine // -1
>> 
>> -BJ
>> 
>> 
>>> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution 
>>> > wrote:
>>> 
>>> I would like to see a full Geometry implementation but I don't think it 
>>> should be part of the standard library.
>>> 
>>> I've kicked around some ideas here: 
>>> 
>>> * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b 
>>> 
>>> * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721 
>>> 
>>> 
>>> and
>>> 
>>> * https://github.com/erica/SwiftGeometry 
>>> 
>>> 
 On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution 
 > wrote:
 
 Hi Evolution,
 
 I would really like to see Swift gain an Angle type in the standard 
 library.  Every time I have to deal with an angle in an api, I have to go 
 figure out the conventions for that call.  Is it in degrees? Is it in 
 radians?  What if it is in radians, but I want to think about it in 
 degrees?
 
 I ended up writing an Angle type for my own code a few years back, and I 
 have to say it is really wonderful.  It has greatly simplified my graphics 
 work.  It takes a lot of mental load off of my brain when dealing with 
 Angles.
 
 I can of course initialize it either as degrees or radians (or 
 revolutions), but I can also just say things like ‘.threeQuarterTurn’, and 
 then I can get the value back out in whatever format I like.  There are 
 also useful additions that let me normalize the angle to different ranges 
 and which let me snap to the nearest multiple of an angle. Both of these 
 are enormously useful for user facing features.  I can also do math on 
 angles in a way that makes geometric sense for angles.  It is also really 
 useful for interacting with CGVectors in intelligent ways.
 
 Using Doubles or CGFloats to represent angles everywhere is just 
 semantically wrong IMHO, and it stops us from adding all of these 
 angle-specific niceties.
 
 Happy to provide code if there is interest…
 
 Thanks,
 Jon
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 

Re: [swift-evolution] [Pitch] Angle Type

[Taylor Swift via swift-evolution]

I do a lot of geometry and spherical-related work and i have never found an 
Angle type to be worth having. Always use radians. It’s what sin() and cos() 
take, it’s what graphics APIs like Cairo expect, it’s what graphics formats 
like SVG use. plus,, do you *really* want to be case-branching on every angle 
value? that really adds up when you’re converting 100,000s of lat-long pairs to 
cartesian.

> On Jan 14, 2018, at 12:04 AM, BJ Homer via swift-evolution 
>  wrote:
> 
> An Angle type already exists in Foundation; see Measurement. You 
> could add some convenience methods in an extension pretty easily.
> 
> import Foundation
> 
> typealias Angle = Measurement
> 
> extension Measurement where UnitType == UnitAngle {
> var sine: Double {
> let radians = self.converted(to: .radians).value
> return sin(radians)
> }
> 
> static var threeQuarterTurn: Angle {
> return Angle(value: 0.75, unit: .revolutions)
> }
> }
> 
> let x = Angle.threeQuarterTurn
> x.sine // -1
> 
> -BJ
> 
> 
>> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution 
>>  wrote:
>> 
>> I would like to see a full Geometry implementation but I don't think it 
>> should be part of the standard library.
>> 
>> I've kicked around some ideas here: 
>> 
>> * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b
>> * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721
>> 
>> and
>> 
>> * https://github.com/erica/SwiftGeometry
>> 
>>> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution 
>>>  wrote:
>>> 
>>> Hi Evolution,
>>> 
>>> I would really like to see Swift gain an Angle type in the standard 
>>> library.  Every time I have to deal with an angle in an api, I have to go 
>>> figure out the conventions for that call.  Is it in degrees? Is it in 
>>> radians?  What if it is in radians, but I want to think about it in degrees?
>>> 
>>> I ended up writing an Angle type for my own code a few years back, and I 
>>> have to say it is really wonderful.  It has greatly simplified my graphics 
>>> work.  It takes a lot of mental load off of my brain when dealing with 
>>> Angles.
>>> 
>>> I can of course initialize it either as degrees or radians (or 
>>> revolutions), but I can also just say things like ‘.threeQuarterTurn’, and 
>>> then I can get the value back out in whatever format I like.  There are 
>>> also useful additions that let me normalize the angle to different ranges 
>>> and which let me snap to the nearest multiple of an angle. Both of these 
>>> are enormously useful for user facing features.  I can also do math on 
>>> angles in a way that makes geometric sense for angles.  It is also really 
>>> useful for interacting with CGVectors in intelligent ways.
>>> 
>>> Using Doubles or CGFloats to represent angles everywhere is just 
>>> semantically wrong IMHO, and it stops us from adding all of these 
>>> angle-specific niceties.
>>> 
>>> Happy to provide code if there is interest…
>>> 
>>> Thanks,
>>> Jon
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Angle Type

[BJ Homer via swift-evolution]

An Angle type already exists in Foundation; see Measurement. You 
could add some convenience methods in an extension pretty easily.

import Foundation

typealias Angle = Measurement

extension Measurement where UnitType == UnitAngle {
var sine: Double {
let radians = self.converted(to: .radians).value
return sin(radians)
}

static var threeQuarterTurn: Angle {
return Angle(value: 0.75, unit: .revolutions)
}
}

let x = Angle.threeQuarterTurn
x.sine // -1

-BJ


> On Jan 13, 2018, at 9:31 PM, Erica Sadun via swift-evolution 
>  wrote:
> 
> I would like to see a full Geometry implementation but I don't think it 
> should be part of the standard library.
> 
> I've kicked around some ideas here: 
> 
> * https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b 
> 
> * https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721 
> 
> 
> and
> 
> * https://github.com/erica/SwiftGeometry 
> 
> 
>> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution 
>> > wrote:
>> 
>> Hi Evolution,
>> 
>> I would really like to see Swift gain an Angle type in the standard library. 
>>  Every time I have to deal with an angle in an api, I have to go figure out 
>> the conventions for that call.  Is it in degrees? Is it in radians?  What if 
>> it is in radians, but I want to think about it in degrees?
>> 
>> I ended up writing an Angle type for my own code a few years back, and I 
>> have to say it is really wonderful.  It has greatly simplified my graphics 
>> work.  It takes a lot of mental load off of my brain when dealing with 
>> Angles.
>> 
>> I can of course initialize it either as degrees or radians (or revolutions), 
>> but I can also just say things like ‘.threeQuarterTurn’, and then I can get 
>> the value back out in whatever format I like.  There are also useful 
>> additions that let me normalize the angle to different ranges and which let 
>> me snap to the nearest multiple of an angle. Both of these are enormously 
>> useful for user facing features.  I can also do math on angles in a way that 
>> makes geometric sense for angles.  It is also really useful for interacting 
>> with CGVectors in intelligent ways.
>> 
>> Using Doubles or CGFloats to represent angles everywhere is just 
>> semantically wrong IMHO, and it stops us from adding all of these 
>> angle-specific niceties.
>> 
>> Happy to provide code if there is interest…
>> 
>> Thanks,
>> Jon
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Pitch] Angle Type

[Erica Sadun via swift-evolution]

I would like to see a full Geometry implementation but I don't think it should 
be part of the standard library.

I've kicked around some ideas here: 

* https://gist.github.com/erica/8cb4b21cf0c429828fad1d8ad459b71b 

* https://gist.github.com/erica/ee06008202c9fed699bfa6254c42c721 


and

* https://github.com/erica/SwiftGeometry

> On Jan 13, 2018, at 7:49 PM, Jonathan Hull via swift-evolution 
>  wrote:
> 
> Hi Evolution,
> 
> I would really like to see Swift gain an Angle type in the standard library.  
> Every time I have to deal with an angle in an api, I have to go figure out 
> the conventions for that call.  Is it in degrees? Is it in radians?  What if 
> it is in radians, but I want to think about it in degrees?
> 
> I ended up writing an Angle type for my own code a few years back, and I have 
> to say it is really wonderful.  It has greatly simplified my graphics work.  
> It takes a lot of mental load off of my brain when dealing with Angles.
> 
> I can of course initialize it either as degrees or radians (or revolutions), 
> but I can also just say things like ‘.threeQuarterTurn’, and then I can get 
> the value back out in whatever format I like.  There are also useful 
> additions that let me normalize the angle to different ranges and which let 
> me snap to the nearest multiple of an angle. Both of these are enormously 
> useful for user facing features.  I can also do math on angles in a way that 
> makes geometric sense for angles.  It is also really useful for interacting 
> with CGVectors in intelligent ways.
> 
> Using Doubles or CGFloats to represent angles everywhere is just semantically 
> wrong IMHO, and it stops us from adding all of these angle-specific niceties.
> 
> Happy to provide code if there is interest…
> 
> Thanks,
> Jon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution