[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 imp

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

e 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, 2017, at 10:26 PM, Taylor

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

afe*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: > > Hi all, I’ve writt

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 stri

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

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

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

On Thu, Jul 13, 2017 at 6:56 PM, Andrew Trick 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 consistency,

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

On Fri, Jul 14, 2017 at 12:22 AM, Andrew Trick wrote: > > On Jul 13, 2017, at 6:55 PM, Taylor Swift wrote: > > > > On Thu, Jul 13, 2017 at 6:56 PM, Andrew Trick wrote: > >> >> On Jul 12, 2017, at 12:16 PM, Taylor Swift via swift-evolution < >> swif

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

On Fri, Jul 14, 2017 at 12:29 AM, Andrew Trick 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 maintain a few libraries

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 would you feel about: >

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) +++ fu

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

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

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 curre

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 itself. I generally

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 a goal. I did >> that with the pointer `

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 wrote: >> >> I'm not sure removing the

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

hrough 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 excellent! I have done every sin

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: 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 wrote: > > How do we feel about ch

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

I don’t really have a strong preference between either `repeating:` or ` value:`, this all kind of seems like bikeshedding to me tbh. If I had to pick one, I’d pick `repeating:` though because that’s what ` Array.init(repeating:count:)` uses, even if it makes a lot of calls sound a little weird. `p

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

ain points for people who need to produce > Unsafe*BufferPointers. > > The rest of the motivation section is excellent! I have done every single > “idiom” you highlight and hated having to do it. > > > On Jul 18, 2017, at 11:19 AM, Andrew Trick via swift-evolution < >

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

gt;> 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 >> jump through and the APIs are not conveniently aligned with them

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 n

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 feature

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 Ada) > have them? By

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

Using the *multiplication operator* as a *separator* character seems like an extraordinarily bad idea. let fsa:[2 * Int] = [2 * 5, 3] // [10, 3] ??? On Sun, Jul 23, 2017 at 11:59 AM, David Sweeris wrote: > > > Sent from my iPhone > > On Jul 23, 2017, at 08:45, Taylor Swift via

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

could > even omit the size and infer the type. > > let fsa = \[1, 2, 3] // Of type \[3: Int] > > And I agree with Taylor that the separator chosen should have no > standalone use in the language — colon, semicolon, pound sign, etc are OK, > but operators shouldn’t be used. > >

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: [2*[5*Int]]". Or, speculating a bit, I suppose may

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 multi-dimensional >> FSAs. Aren’t they the same thing? F

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

x27;, nor '::' is particularly 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 wrote: > > > On Jul 23, 2017, at 3:18 PM, Taylor Swift via swi

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

On Sun, Jul 23, 2017 at 5:48 PM, David Sweeris wrote: > > On Jul 23, 2017, at 12:18, Taylor Swift wrote: > > 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 y

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 Sweeris > wrote: > >> >> On Jul 23, 2017, at 1

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, 2

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

e 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, philohan95 via swift-evolution < >&

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: > Hel

[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 pow(

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

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@swift.org> wrote:

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?

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, Taylor Swift

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

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, Taylor Swift

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 editors

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

On Mon, Jul 31, 2017 at 7:20 PM, David Sweeris 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] [Idea] Custom keywords for operators.

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 operator overloading, and I think supporting this >> wou

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

: Self) -> Self >>> static func log(_ value: Self, base: Self) -> Self >>> static func pow(_ value: Self, exponent:Self) -> Self >>> static func exp(_ value: Self) -> Self >>> } >>> >>> It does not pollute the glo

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

g! If we ever got an “official” math module started, I think it would make a great seed. > On Mon, Jul 31, 2017 at 7:37 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > >> I’d be completely in favor of this. Structs for priority queues, >> s

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

should play nice with most client projects. On Tue, Aug 1, 2017 at 4:50 AM, Ian Partridge wrote: > On 1 August 2017 at 04:46, Taylor Swift via swift-evolution > wrote: > > I’m not saying the Swift team should devote any time or resources to > writing > > these things, but it’d

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 (T

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 wrote: > > On Aug 1, 2017, at 8:02 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > I think the Server APIs project was pretty c

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

On Tue, Aug 1, 2017 at 1:20 PM, Michael Ilseman 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 > libraries we want, but th

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 > consens

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 tea

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

On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu 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 < >> swift-evolution@swift.org>

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

I agree with this, extensions on types defined in the same file are generally silly, and default implementations belong in the protocol body. I don’t agree with certain style guides prescription of same-file extensions; they should only be used to hide protocol conformances that are “unimportant” t

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 def

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

t;> On Tue, Aug 1, 2017 at 5:50 PM, Xiaodi Wu 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

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 o

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 take

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

On Wed, Aug 2, 2017 at 7:54 PM, Xiaodi Wu wrote: > On Wed, Aug 2, 2017 at 6:29 PM, Taylor Swift wrote: > >> 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 yourselv

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 >>> wrote: >>> See, my problem with statements like this one, is that the

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

Trying to gather together a bunch of unpaid people won’t automatically solve the problem. (We *can* agree that there *is* a problem, yes?) I think Swift Breeze demonstrated that. (Incidentally, throwing a bunch of money at the problem won’t automatically solve it either — look at the US government.

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 never

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, doesn't GitHub itself fit the roles you define

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?

i reached out to the person running that repository a few months ago but they never responded. On Thu, Aug 3, 2017 at 12:38 PM, Jacob Williams via swift-evolution < swift-evolution@swift.org> wrote: > There’s also a PureSwift organization of GitHub that has several Swift PM > packages built speci

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 most

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 ge

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

On Thu, Aug 3, 2017 at 3:29 AM, Tino Heth <2...@gmx.de> wrote: > > Well that there is a rather defeatist attitude. If you are correct that > Apple-funded development is the only way to get core libraries built (and > maintained), and Apple has expressed they have no intention of doing so, > then w

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 perform

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

On Thu, Aug 3, 2017 at 7:17 PM, Karl Wagner 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(_:) in pure generic Swift code, with

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> w

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

, 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: > >> In an effort to g

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

On Thu, Aug 3, 2017 at 8:20 PM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > The root cause, of course, is that the VLAs require new stack allocations > each time, and the stack is only deallocated as one lump when the frame > ends. > > > That is true of alloca(), but no

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

On Thu, Aug 3, 2017 at 11:17 PM, Karl Wagner 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 < > swift-evolution@swift.org> wrot

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 you do a lot of graphic

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

stant 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, Karl Wagner via swi

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] 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’

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 more like an argument for post

[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] SE-184 Improved Pointers

On Tue, Aug 8, 2017 at 7:53 PM, Andrew Trick wrote: > > On Aug 8, 2017, at 9:52 AM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Since Swift 5 just got opened up for proposals, SE-184 Improved Pointers > is ready for community review, and

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 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: size, alignedTo: >> Me

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:) >>> >>> Well, I think it's somewhat ridiculous for users to wri

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

cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cannot find such a function anywhere in the API. There is copyBytes(from:) , but the documentation is messed up and mentions a nonexisten

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 isKnownUniquelyRefe

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, exactly. An Array i

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] 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 wrote: >> >> cool,, as for UnsafeMutableRawBufferPointer.copy(from:bytes:), I cann

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 s

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, 2017, at 12:35 AM, Félix Cloutier >> wrote: >>

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 wrote: > >> >> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: >> >> >> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: >

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 p

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

Implementation is here: https://github.com/apple/swift/pull/11464 On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift wrote: > 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 t

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

I know this has come up before without any action, but having the standard C library be packaged under `Darwin` on OSX and `Glibc` under Linux is something that’s really becoming an issue as the Swift package ecosystem matures. Right now a lot of packages are a lot less portable than they could be

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

On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar 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 the > standard C library be p

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

On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar > 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 the

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

hat 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.python.org/2/library/os

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

t;>> >>>> Python’s os.path <https://docs.python.org/2/library/os.path.html> is a >>>> nice abstract model for doing path manipulations. Maybe Swift could get a >>>> struct like `Filepath` or something on which these operations could be >>>>

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

On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote: > > On Aug 17, 2017, at 6:56 PM, Xiaodi Wu wrote: > > On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadun wrote: > >> What people are doing is taking a real set of values (1, 2, 3, 4, 5, for >> example)

  1   2   >