Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

There was a sign error due to switching to an underlying approximation of sin() to evaluate cos(). Here’s the actual output On Fri, Aug 4, 2017 at 4:56 PM, Taylor Swift wrote: > update: > > I’

[swift-evolution] Reminder: Swift.org scheduled outages for bug reporting, mailing lists, website and CI

Just a reminder, the mailing list server and CI will be going offline in about an hour. > On Aug 2, 2017, at 4:52 PM, Nicole Jacque wrote: > > Hello All- > > We will have some downtime for swift.org resources over > the weekend as we upgrade our infrastructure. > > The

Re: [swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

update: I’ve managed to improve the algorithm to the point where it’s arguably more accurate than Glibc.cos(_:), and runs just as fast. Removing one term makes the Swift implementation faster than _cos(_:), but worses the divergence by like 23% (137 ULPs from 0° ..< 90°, as opposed to 111 ULPs).

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Ah, I see. I understood on a basic level that additive features were safe, but I didn't/don't have the knowledge to judge when adding actually means changing (e.g. idk, 'adding abstract classes' or 'adding optional protocol methods' implying 'changing/breaking inheritance/dispatch' or something..).

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

Sorry, not sure how I missed that 😑. > On Aug 4, 2017, at 3:16 PM, Félix Cloutier wrote: > > >> Le 4 août 2017 à 11:39, Robert Bennett a écrit : >> >>> That's not a concern with the `let` case that Robert brought up, since you >>> can't mutate a `let` array at all. >>> >>> The big thing is

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 4, 2017, at 12:03 PM, Mathew Huusko V wrote: > > Thanks for the swift response, it's an honour; I agree wholeheartedly with > your logic and sentiment. Sorry if I was unclear, but my concern/curiosity is > not for the speed of Swift's development, but in fact for its long term > evol

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> Le 4 août 2017 à 11:39, Robert Bennett a écrit : > >> That's not a concern with the `let` case that Robert brought up, since you >> can't mutate a `let` array at all. >> >> The big thing is that unconstrained escape analysis is uncomputable. Since >> Swift array storage is COW, any function

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Thanks for the swift response, it's an honour; I agree wholeheartedly with your logic and sentiment. Sorry if I was unclear, but my concern/curiosity is not for the speed of Swift's development, but in fact for its long term evolution and longevity. At risk of repeating myself/boring everyone, that

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> That's not a concern with the `let` case that Robert brought up, since you > can't mutate a `let` array at all. > > The big thing is that unconstrained escape analysis is uncomputable. Since > Swift array storage is COW, any function that receives the array as a > parameter is allowed to take

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

> On Aug 4, 2017, at 1:19 PM, Félix Cloutier via swift-evolution > wrote: > > That's not a concern with the `let` case that Robert brought up, since you > can't mutate a `let` array at all. > > The big thing is that unconstrained escape analysis is uncomputable. Since > Swift array storage i

Re: [swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

> On Aug 4, 2017, at 9:16 AM, Mathew Huusko V via swift-evolution > wrote: > > Per > https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html > > , > the removal of parameter labels ent

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

That's not a concern with the `let` case that Robert brought up, since you can't mutate a `let` array at all. The big thing is that unconstrained escape analysis is uncomputable. Since Swift array storage is COW, any function that receives the array as a parameter is allowed to take a reference

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

I've never seen the Swift compiler put array storage on automatic storage, even for small arrays. I don't think that it has much to do with their size, though (for any array that is not incredibly large). > Le 3 août 2017 à 23:18, David Hart a écrit : > > Don’t small arrays live on the stack?

Re: [swift-evolution] Why you can't make someone else's class Decodable: a long-winded explanation of 'required' initializers

To clarify a bit here — this isn’t a "privilege" so much so as a property of the design of these classes. `NSData`, `NSString`, `NSArray`, and some others, are all known as _class clusters_; the classes you know and use are essentially abstract base classes whose implementation is given in priva

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

No, that doesn’t work. In many cases you want to mutate the elements of the array without changing its size. For example, a Camera struct which contains a matrix buffer, and some of the matrices get updated on each frame that the camera moves. The matrix buffer also stores all of the camera’s store

[swift-evolution] [planning] [discussion] Schedule for return of closure parameter labels (+ world domination ramble)

Per https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000233.html, the removal of parameter labels entirely was accepted as a temporary loss for Swift 3 as a means to remove them from the type system. I'm wondering if they're coming back (syntactically) any time soon? Other than

Re: [swift-evolution] [Planning][Request] "constexpr" for Swift 5

So, I’m getting into this thread kind of late, and I’ve only skimmed most of it, but… A special FSA on the stack seems like the wrong direction. Wouldn’t it make more sense to have *all* value types that don’t change in size — including `let` Arrays — live on the stack? In which case, FSA would