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

aking them computed properties but I believe there was a big fuss a while back about why signum() had to be a method and not a property so I’m just going off of that. > > Sent from my iPhone. > > > On Jul 31, 2017, at 1:03 PM, Taylor Swift via swift-evolution < > swift-evolution@swi

[swift-evolution] TrigonometricFloatingPoint/MathFloatingPoint protocol?

How would people feel about adding a protocol protocol MathFloatingPoint:FloatingPoint { func sin() -> Self func cos() -> Self func tan() -> Self func asin() -> Self func acos() -> Self func atan() -> Self func ln() -> Self func log(base:Self) -> Self func

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

f it benefits from the same inlining and specialization as the standard library. Also squareRoot() should be moved to the Math module if it is ever created. > Am 31. Juli 2017 um 19:03:49, Taylor Swift via swift-evolution ( > swift-evolution@swift.org) schrieb: > > How would

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

elf > } > > It does not pollute the global namespace and gives nice contextual > auto-completion. And I don’t want it in the standard library: I only add > the file when I need it. (it is not a separate module for optimization > reasons). > > On Jul 31, 2017, at 10:29 AM

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

See, my problem with statements like this one, is that the answer “should be supported as a third-party library” can also be interpreted as “not my problem, go figure it out yourselves”. The idea that central entity can only pay attention to what they want to, and the Community™ will magically

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

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > >> On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < &g

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

On Wed, Aug 2, 2017 at 9:18 PM, Xiaodi Wu wrote: > On Wed, Aug 2, 2017 at 7:29 PM, Taylor Swift wrote: > >> >> >> On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu wrote: >> >>> On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift

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

Swift Breeze *was* on Github ,, i don’t know whose argument that strengthens here :) Here was the original thread it was introduced in. It got a lot of attention and +1’s but

Re: [swift-evolution] [Pitch] New Version of Array Proposal

FSA indices may be nominal, but you still need some way to store them. A good example of this is when you’re implementing cubemaps with 3-tuple vectors. Selecting a cube face involves selecting components of the vector at a variable offset supplied by a function parameter. Doing this with a switch

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

On Wed, Aug 2, 2017 at 10:58 PM, Xiaodi Wu wrote: > On Wed, Aug 2, 2017 at 21:55 Taylor Swift wrote: > >> Swift Breeze *was* on Github ,, i don’t >> know whose argument that strengthens here :) >> > > No, no, I mean,

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

On Thu, Aug 3, 2017 at 3:21 AM, Tino Heth <2...@gmx.de> wrote: > > You're welcome to join me in my endeavor to create a math library. I'd bet > Karoly feels the same way about his project. > > See, exactly this is the big problem we are facing here — probably not in > your specific case, but in

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

I don’t think we should be designing interfaces based off of what pure mathematicians write. Scientists aren’t the only people who use sin(x). It’s better to go with the “common sense” behavior than the esoteric academic notation. And for the record, I think Matrix.map(sin(_:)) is the best and

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

In an effort to get this thread back on track, I tried implementing cos(_:) in pure generic Swift code, with the BinaryFloatingPoint protocol. It deviates from the _cos(_:) intrinsic by no more than 5.26362703423544e-11. Adding more terms to the approximation only has a small penalty to the

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

For what it’s worth, I’d be happy with just subscripts on tuples and some form of shorthand for their size. Maybe (Float ... 5) or something like that. That would obviate the need for an attribute too. On Thu, Aug 3, 2017 at 11:48 PM, Karl Wagner wrote: > > Actually, if

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

On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner <razie...@gmail.com> wrote: > > On 4. Aug 2017, at 02:44, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution <

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

On Thu, Aug 3, 2017 at 7:17 PM, Karl Wagner <razie...@gmail.com> wrote: > > On 3. Aug 2017, at 20:52, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > In an effort to get this thread back on track, I tried implementing > cos(

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

On Thu, Aug 3, 2017 at 7:12 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > On 3. Aug 2017, at 13:04, Stephen Canon via swift-evolution < > swift-evolution@swift.org> wrote: > > On Aug 2, 2017, at 7:03 PM, Karl Wagner via swift-evolution < > swift-evolution@swift.org>

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

special values. *On the long term*, it should ideally be able to use SIMD > instructions when applied to arrays/matrices or when the compiler can > autovectorize some loops. > > On Thu, Aug 3, 2017 at 8:52 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote:

Re: [swift-evolution] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 10:43 AM, Daryle Walker via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 8, 2017, at 6:45 PM, Geordie Jay wrote: > > > Daryle Walker via swift-evolution schrieb am > Di. 8. Aug. 2017 um 21:25: > >> On Aug 8,

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: > > > On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 8:44 PM, Taylor Swift

Re: [swift-evolution] SE-184 Improved Pointers

Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick <atr...@apple.com> wrote: > >> >> On Aug 8, 2017, at 11:10 PM, Taylor Swift <kelvin1...@gmail.com> wrote: >> >> >> On

Re: [swift-evolution] SE-184 Improved Pointers

I’ve revised the proposal based on what I learned from trying to implement these changes. I think it’s worth tacking the existing methods that take Sequences at the same time as this actually makes the design a bit simpler. *The

Re: [swift-evolution] Pitch: Improved Swift pointers

On Fri, Jul 14, 2017 at 12:22 AM, Andrew Trick <atr...@apple.com> wrote: > > On Jul 13, 2017, at 6:55 PM, Taylor Swift <kelvin1...@gmail.com> wrote: > > > > On Thu, Jul 13, 2017 at 6:56 PM, Andrew Trick <atr...@apple.com> wrote: > >> >> O

Re: [swift-evolution] Pitch: Improved Swift pointers

On Fri, Jul 14, 2017 at 12:29 AM, Andrew Trick <atr...@apple.com> wrote: > > On Jul 13, 2017, at 6:16 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > I am not very familiar with the inner workings of the standard library, > however I

Re: [swift-evolution] Pitch: Improved Swift pointers

I am not very familiar with the inner workings of the standard library, however I maintain a few libraries which make extensive use of Swift pointers, such as https://github.com/kelvin13/maxpng which makes extensive use of Unsafe_Pointers. I also write a lot of code that interfaces with C APIs

Re: [swift-evolution] Pitch: Improved Swift pointers

as problematic as the memory allocation API and deserve a closer look. Here’s a new version of the proposal with revisions <https://gist.github.com/kelvin13/a9c033193a28b1d4960a89b25fbffb06> On Wed, Jul 12, 2017 at 6:46 PM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: &g

Re: [swift-evolution] Pitch: Improved Swift pointers

On Thu, Jul 13, 2017 at 6:56 PM, Andrew Trick <atr...@apple.com> wrote: > > On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Hi all, I’ve written up a proposal to modify the unsafe pointer API for > greater

Re: [swift-evolution] [Review] SE-0182 - String Newline Escaping

as is, this will mess up the “collapse” feature in most text editors,, it should not be added unless indentation removal is added too On Wed, Jul 12, 2017 at 7:48 PM, T.J. Usiyan via swift-evolution < swift-evolution@swift.org> wrote: > +1 > > Maintaining parity between single and multi line

Re: [swift-evolution] Pitch: Improved Swift pointers

I’d also like to swap the ordering of `count:` and `to:` in ` UnsafeMutableRawPointer.initializeMemory(as:at:count:to:)` so it matches up with the ordering in `UnsafeMutablePointer.initializeMemory(to:count:) `. On Fri, Jul 14, 2017 at 12:33 PM, Taylor Swift wrote: > How

Re: [swift-evolution] Pitch: Improved Swift pointers

How would you feel about: struct UnsafeMutableRawBufferPointer { --- static func allocate(count:Int) -> UnsafeMutableRawBufferPointer +++ static func allocate(bytes:Int, alignedTo:Int) -> UnsafeMutableRawBufferPointer func deallocate() +++ func bindMemory(to:Element.Type, capacity:Int) +++

Re: [swift-evolution] Pitch: Improved Swift pointers

13, 2017, at 6:55 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Thu, Jul 13, 2017 at 6:56 PM, Andrew Trick <atr...@apple.com> wrote: > >> >> On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution < >> sw

Re: [swift-evolution] Pitch: Improved Swift pointers

I’ve drafted a new version of the unsafe pointer proposal based on feedback I’ve gotten from this thread. You can read it here . ~~~ Swift’s pointer types are an important interface for low-level memory manipulation, but the

Re: [swift-evolution] Pitch: Improved Swift pointers

On Tue, Jul 18, 2017 at 2:18 PM, Andrew Trick wrote: > > > rename count in UnsafeMutableRawBufferPointer.allocate(count:) to bytes > and add an > > alignedTo parameter to make it UnsafeMutableRawBufferPointer. > allocate(bytes:alignedTo:) > > Memory allocation is an issue unto

Re: [swift-evolution] Pitch: Improved Swift pointers

On Tue, Jul 18, 2017 at 5:20 PM, Taylor Swift wrote: > No, I just forgot about the compiler subtyping relationship. Never mind > that part then lol > > On Tue, Jul 18, 2017 at 4:40 PM, Andrew Trick wrote: > >> >> On Jul 18, 2017, at 11:36 AM, Taylor Swift

Re: [swift-evolution] Pitch: Improved Swift pointers

No, I just forgot about the compiler subtyping relationship. Never mind that part then lol On Tue, Jul 18, 2017 at 4:40 PM, Andrew Trick wrote: > > On Jul 18, 2017, at 11:36 AM, Taylor Swift wrote: > > I'm not sure removing the need for implicit casts is

Re: [swift-evolution] Pitch: Improved Swift pointers

es and hoops to jump through and the APIs are not conveniently > aligned with them. I do think you’ve done a great job of correctly > identifying the pain points for people who need to produce > Unsafe*BufferPointers. > > Good point > The rest of the motivation section is exce

Re: [swift-evolution] Pitch: Improved Swift pointers

What about `value:`? `ptr.initialize(value: value)` `ptr.initialize(value: value, count: 13)` `ptr.initialize(as: UInt16.self, at: 0, value: value, count: 13)` On Wed, Jul 19, 2017 at 12:01 PM, Andrew Trick wrote: > > On Jul 18, 2017, at 9:42 PM, Taylor Swift

Re: [swift-evolution] Pitch: Improved Swift pointers

How do we feel about changing the label to `repeated:`, even in cases where `count:` is 1? This would mean that calls would read like this: `ptr.initialize(repeated: value)` A grep through the stdlib shows that this is by far the most common use case: swift-source/swift$ grep initialize\(to: .

Re: [swift-evolution] [Pitch] New Version of Array Proposal

Hi, I’ve been watching this proposal for a while but didn’t get to read it in detail until now. I really like this idea and it’s very comprehensive and well-thought out. Some feedback: 1. I got very confused reading through the document the first time through. You’re introducing a huge amount of

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

I’d be in favor of this. On Tue, Jul 25, 2017 at 5:44 AM, philohan95 via swift-evolution < swift-evolution@swift.org> wrote: > I think the current way to initiate models in a Failable Initializer > `init?()` is overly verbose and should be shortened down so less > boilerplate should be needed. >

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

Catching and throwing exceptions is not the same as a controlled guard fail. It’s also quite verbose and requires extra types to be defined outside the scope of the initializer. On Tue, Jul 25, 2017 at 5:35 PM, Rob Mayoff via swift-evolution < swift-evolution@swift.org> wrote: > On Tue, Jul 25,

Re: [swift-evolution] Idea: Properties in Failable Initializers less verbose

e protocol in Swift 4 will eliminate most cases > where this is really a problem. > > On Wed, 26 Jul 2017 at 02:30 Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’d be in favor of this. >> >> On Tue, Jul 25, 2017 at 5:44 AM, philohan

Re: [swift-evolution] [Pitch] New Version of Array Proposal

On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker wrote: > > 9. I don’t see the value in having both nested FSAs and multi-dimensional > FSAs. Aren’t they the same thing? For example, in the code snippet > > > Why does any language with multi-dimensional arrays (like Fortran or

Re: [swift-evolution] [Pitch] New Version of Array Proposal

5, 3] // [10, 3] ??? > > On Sun, Jul 23, 2017 at 11:59 AM, David Sweeris <daveswee...@mac.com> > wrote: > >> >> >> Sent from my iPhone >> >> On Jul 23, 2017, at 08:45, Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >&g

Re: [swift-evolution] [Pitch] New Version of Array Proposal

On Sun, Jul 23, 2017 at 5:29 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote: > I wanted to read the proposal, but skipped it as soon as I’ve seen the > syntax. From the esthetic point of you the proposed syntax is really ugly. > Again I’m not speaking against the

Re: [swift-evolution] [Pitch] New Version of Array Proposal

On Sun, Jul 23, 2017 at 2:21 PM, David Sweeris wrote: > > On Jul 23, 2017, at 09:08, Taylor Swift wrote: > > let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ??? > > > Correct. If you wanted a multidimensional array, that'd be written "let > nestedFSA:

Re: [swift-evolution] [Pitch] New Version of Array Proposal

readable, and compiler parser code only needs to be written once, while language syntax, once it’s decided on, is stuck with us forever. On Sun, Jul 23, 2017 at 11:05 PM, Daryle Walker <dary...@mac.com> wrote: > > > On Jul 23, 2017, at 3:18 PM, Taylor Swift via swift-evolution <

Re: [swift-evolution] [Pitch] New Version of Array Proposal

On Sun, Jul 23, 2017 at 11:05 PM, Daryle Walker wrote: > > > > On Jul 23, 2017, at 12:04 PM, Taylor Swift wrote: > > > > On Sun, Jul 23, 2017 at 3:08 AM, Daryle Walker wrote: > >> >> 9. I don’t see the value in having both nested FSAs and

Re: [swift-evolution] [Pitch] New Version of Array Proposal

This proposal gives FSAs their own literal syntax. You write [; 3, 5] to make a FSA, not [3, 5]. On Sun, Jul 23, 2017 at 11:54 PM, David Sweeris wrote: > > On Jul 23, 2017, at 8:32 PM, Taylor Swift wrote: > > On Sun, Jul 23, 2017 at 5:48 PM, David

Re: [swift-evolution] Pitch: Improved Swift pointers

y allocated, initialized, and >> pointer-casted, it is very convenient for *consumers* >> of Unsafe*BufferPointers. The main pain points, and this proposal is >> excellent at addressing, are on the *producers* of >> Unsafe*BufferPointers. For producers, there are a lot of rules and hoops to

[swift-evolution] Pitch: Improved Swift pointers

Hi all, I’ve written up a proposal to modify the unsafe pointer API for greater consistency, safety, and ease of use. ~~~ Swift currently offers two sets of pointer types — singular pointers such as UnsafeMutablePointer, and vector (buffer) pointers such as UnsafeMutable *Buffer*Pointer. This

Re: [swift-evolution] Pitch: Improved Swift pointers

enamed to CStructPointer, due to the fact that > all non-C usages of this type should be replaced by usage of UnsafeAddress > . > And the AutoreleasingUnsafeMutablePointer would also be a thing wrapper > around UnsafeAddress with a possible renaming to NSObjectPointer. > > On Jul 12

Re: [swift-evolution] Pitch: Improved Swift pointers

allocate/deallocate to Unsafe*BufferPointer, > then you probably also want to consider doing the same for initialize, > deinitialize, and various move functions as well. > > On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > >

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

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] Change 'for in' expression to for [] { (item) in ... }

This is funny because this “expected behavior” is actually a heavily criticized part of C behavior. I think this change would cause just as much if not more confusion than it alleviates. On Fri, Jul 28, 2017 at 12:19 PM, Kwanghoon Choi via swift-evolution < swift-evolution@swift.org> wrote: >

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick wrote: > > > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >> >> Well, I think it's somewhat ridiculous for users to write this every time >> they allocate a buffer: >> >> `UnsafeMutableRawBufferPointer.allocate(bytes:

Re: [swift-evolution] [Draft] Refining identifier and operator symbology (take 2)

Real Swift code uses very very few “unicode” operators, so I would heavily tilt the division towards making most characters identifiers. While I don’t want to talk about specific characters, I often wish I could name variables `∇f` or `∂u∂v`, while no sane API designer would ever use `∇` or `∂` as

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 11:24 PM, Andrew Trick wrote: > > On Aug 8, 2017, at 6:51 PM, Taylor Swift wrote: > > > > On Tue, Aug 8, 2017 at 9:38 PM, Andrew Trick wrote: > >> >> > UnsafeMutableRawBufferPointer.allocate(bytes:alignedTo:) >>>

Re: [swift-evolution] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < swift-evolution@swift.org> wrote: > Yes, exactly. An Array is a struct wrapper for a reference type > representing storage. Mutating functions first check if they own the only > reference to the storage using

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 1:50 AM, Rob Mayoff wrote: > On Tue, Aug 8, 2017 at 11:51 PM, Taylor Swift via swift-users < > swift-us...@swift.org> wrote: > >> >> >> On Wed, Aug 9, 2017 at 12:29 AM, Félix Cloutier via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> Yes,

Re: [swift-evolution] SE-184 Improved Pointers

On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: > > On Aug 8, 2017, at 8:44 PM, Taylor Swift wrote: > > cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot > find such a function anywhere in the API. There is copyBytes(from:) >

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

this should play nice with most client projects. On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge <i...@poncho.org.uk> wrote: > On 1 August 2017 at 04:46, Taylor Swift via swift-evolution > <swift-evolution@swift.org> wrote: > > I’m not saying the Swift team should devote any time o

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

I’ve noticed from this and older threads that everyone agrees on what core libraries we want, but they never actually get built. Perennial requests seem to be - RNG and cryptography library (CryptoSwift could be a good base for this) - Generic Math library/Vector library - Basic data structures

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

modifiers. Not ideal, but I’m glad this won’t be the situation forever. On Tue, Aug 1, 2017 at 12:45 PM, Michael Ilseman <milse...@apple.com> wrote: > > On Aug 1, 2017, at 8:02 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > I think the Ser

Re: [swift-evolution] [Idea] Custom keywords for operators.

On Mon, Jul 31, 2017 at 7:20 PM, David Sweeris <daveswee...@mac.com> wrote: > > > On Jul 31, 2017, at 3:59 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I’m gonna come out and say I’m not a fan of this at all. I’m alr

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

) -> Self >>> static func atan(_ value: Self) -> Self >>> >>> static func ln(_ value: Self) -> Self >>> static func log(_ value: Self, base: Self) -> Self >>> static func pow(_ value: Self, exponent:Self) -> Self >>>

Re: [swift-evolution] [Idea] Custom keywords for operators.

I’m gonna come out and say I’m not a fan of this at all. I’m already pretty suspicious of operator overloading, and I think supporting this would make Swift code much more difficult to read. Also, while for some reason everyone ignores this, this kind of syntax is almost impossible for text

Re: [swift-evolution] [Idea] Custom keywords for operators.

swee...@mac.com> > wrote: > >> >> > On Jul 31, 2017, at 3:59 PM, Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >> > >> > I’m gonna come out and say I’m not a fan of this at all. I’m already >> pretty suspicious of

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

On Tue, Aug 1, 2017 at 1:20 PM, Michael Ilseman <milse...@apple.com> wrote: > > > On Aug 1, 2017, at 8:14 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > I’ve noticed from this and older threads that everyone agrees on what core >

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

On Tue, Aug 1, 2017 at 1:44 PM, Tino Heth <2...@gmx.de> wrote: > > So, this has been discussed before on the list many times in the past. The > core team has stated that their preferred process for this is to have > individuals write their own libraries, get real-world adoption, then (as >

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

On Tue, Aug 1, 2017 at 1:51 PM, Michael Ilseman via swift-evolution < swift-evolution@swift.org> wrote: > > > On Aug 1, 2017, at 10:44 AM, Tino Heth via swift-evolution < > swift-evolution@swift.org> wrote: > > > So, this has been discussed before on the list many times in the past. The > core

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

e: > >> >> >> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: >> >>> >>> On Tue, Aug 1, 2017 at 13:00 Taylor Swift via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

I don’t understand how extensions help with code locality. It’s literally a matter of *curly braces*. I already glue the extension block to the bottom } of the protocol block anyway by omitting the empty linebreak. protocol Protocol { func default_function() } extension Protocol { func

Re: [swift-evolution] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

i would have written it like this < https://gist.github.com/kelvin13/ba42b620f80ee94fbb0d0841056aac97> On Wed, Aug 2, 2017 at 12:34 PM, Gor Gyolchanyan < gor.f.gyolchan...@icloud.com> wrote: > > On Aug 2, 2017, at 7:31 PM, Tino Heth <2...@gmx.de> wrote: > > > Consider these two alternative ways

[swift-evolution] SE-184 Improved Pointers

Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers is ready for community review, and I encourage everyone to look it over and provide feedback. Thank you! < https://github.com/apple/swift-evolution/blob/master/proposals/0184-improved-pointers.md >

Re: [swift-evolution] [swift-users] How does "Sequence.joined" work?

On Wed, Aug 9, 2017 at 5:54 AM, Daniel Vollmer via swift-evolution < swift-evolution@swift.org> wrote: > > > On 9. Aug 2017, at 06:51, Taylor Swift via swift-users < > swift-us...@swift.org> wrote: > > > > It’s possible to implement a classic red-black tree in Swift that > performs better than a

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

: > > Where do constant Arrays currently live? I hope the answer is on the > stack, since their size doesn’t change. > > On Aug 3, 2017, at 8:44 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > On Thu, Aug 3, 2017 at 8:20 PM, Kar

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

On Mon, Aug 7, 2017 at 12:12 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > > > On Aug 7, 2017, at 12:43 AM, Elviro Rocca com> wrote: > > > > I read many times the "most users don't care about this" objection but I > always considered it

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

On Fri, Aug 18, 2017 at 1:23 PM, Erica Sadun wrote: > I want to avoid breaking math. > it’s not that deep,,, the `for _ in 0 ..< n` loop is exactly the same thing except more verbose. In fact, that’s how your proposed ` Array.init(count:generator:)` would be implemented.

Re: [swift-evolution] pitch: Unified libc import (again)

om> wrote: > > > On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <daniel_dun...@apple.com> > wrote: > >> >> > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >> > >> > I know th

Re: [swift-evolution] pitch: Unified libc import (again)

On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar <daniel_dun...@apple.com> wrote: > > > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > > > I know this has come up before without any action, but having

Re: [swift-evolution] pitch: Unified libc import (again)

upposed to be the core library that provides file system > access facilities. What’s missing, and can we add it to Foundation? > > On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > >> Python’s os.path <https://docs.py

Re: [swift-evolution] SE-184 Improved Pointers

Should the immutable buffer pointer types also get deallocate()? On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick <atr...@apple.com> wrote: > > On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Implementation is her

Re: [swift-evolution] pitch: Unified libc import (again)

On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu wrote: > On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker wrote: > >> >> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Thu, Aug 17, 2017 at 6:46 PM, Taylor

Re: [swift-evolution] pitch: Unified libc import (again)

ibrary as a TextOutputStream. >>> >>> * Foundation is supposed to be the core library that provides file >>> system access facilities. What’s missing, and can we add it to Foundation? >>> >>> On Thu, Aug 17, 2017 at 17:50 Taylor Swift via swift-evolution <

Re: [swift-evolution] pitch: Unified libc import (again)

On Thu, Aug 17, 2017 at 11:19 PM, Xiaodi Wu wrote: > On Thu, Aug 17, 2017 at 22:06 Taylor Swift wrote: > >> Okay I can sense this thread getting derailed so I’ll try to address your >> comments one by one. >> >> * stderr should go wherever stdin and

Re: [swift-evolution] SE-184 Improved Pointers

drew Trick <atr...@apple.com> wrote: > >> >> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> Implementation is here: https://github.com/apple/swift/pull/11464 >> >> On Sat, Aug 12,

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 6:05 PM, Andrew Trick wrote: > > On Aug 9, 2017, at 8:51 AM, Taylor Swift wrote: > > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 11:10 PM, Taylor Swift

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: > > What you’re describing is basically an earlier version of the proposal > which had a slightly weaker precondition (source >= destination) than

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > >> >> On Aug 19, 2017, at 6:16 PM, Taylor Swift

Re: [swift-evolution] SE-184 Improved Pointers

, Aug 19, 2017 at 6:02 PM, Andrew Trick <atr...@apple.com> wrote: > > On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Implementation is here: https://github.com/apple/swift/pull/11464 > > On Sat, Aug 12, 2017

Re: [swift-evolution] SE-184 Improved Pointers

On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick wrote: > >> The problem is I would expect to be able to safely call deinitialize() >> and friends after calling initialize(from:). If Element is a class type and >> initialize doesn’t fill the entire buffer range, calling

Re: [swift-evolution] SE-184 Improved Pointers

What you’re describing is basically an earlier version of the proposal which had a slightly weaker precondition (source >= destination) than yours (source == destination). That one basically ignored the Sequence methods at the expense of greater API surface area. On Sat, Aug 19, 2017 at 9:08 PM,

Re: [swift-evolution] SE-184 Improved Pointers

, at: 2, from: source, count: 5) On Sun, Aug 20, 2017 at 12:12 AM, Taylor Swift via swift-evolution < swift-evolution@swift.org> wrote: > > > On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick <atr...@apple.com> wrote: > >> >> On Aug 19, 2017, at 6:42 PM, Taylo

[swift-evolution] (core library) modern URL types

Okay so a few days ago there was a discussion about getting pure swift file system support into Foundation or another core library, and in my opinion, doing this requires a total overhaul of the `URL` type (which

Re: [swift-evolution] SE-184 Improved Pointers

On Sun, Aug 20, 2017 at 10:18 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 9:12 PM, Taylor Swift wrote: > >> >> and the other methods should take both an *offset* parameter instead of >> a count parameter: >> >> initialize(from:at:) >> assign(from:at:)

Re: [swift-evolution] SE-184 Improved Pointers

Sun, Aug 20, 2017 at 1:40 PM, Kelvin Ma <kelvin1...@gmail.com> wrote: > actually never mind that, UnsafeMutablePointer should be the only type to > not support at: arguments since offsetting them is easy with +. > > On Aug 20, 2017, at 12:12 AM, Taylor Swift via swift-evolution

Re: [swift-evolution] (core library) modern URL types

to handle local > and remote resources, so that at least developers have to be explicit about > allowing remote resources. This makes a new URL type less necessary towards > supporting file I/O. > > Félix > > Le 20 août 2017 à 21:37, Taylor Swift via swift-evolution < > swift-

Re: [swift-evolution] SE-184 Improved Pointers

On Tue, Aug 22, 2017 at 2:35 AM, Andrew Trick wrote: > > On Aug 21, 2017, at 10:59 PM, Taylor Swift wrote: > > Sorry to bring this up again, but I was not able to defend the addition of >> `UnsafeMutableBufferPointer.deinitialize()`. It is incorrect for

  1   2   >