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

2017-07-31 Thread Taylor Swift via swift-evolution
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?

2017-07-31 Thread Taylor Swift via swift-evolution
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?

2017-07-31 Thread Taylor Swift via swift-evolution
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?

2017-07-31 Thread Taylor Swift via swift-evolution
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?

2017-08-02 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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?

2017-08-02 Thread Taylor Swift via swift-evolution
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?

2017-08-02 Thread Taylor Swift via swift-evolution
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

2017-08-02 Thread Taylor Swift via swift-evolution
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?

2017-08-02 Thread Taylor Swift via swift-evolution
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?

2017-08-03 Thread Taylor Swift via swift-evolution
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?

2017-08-03 Thread Taylor Swift via swift-evolution
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?

2017-08-03 Thread Taylor Swift via swift-evolution
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

2017-08-03 Thread Taylor Swift via swift-evolution
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

2017-08-03 Thread Taylor Swift via swift-evolution
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?

2017-08-03 Thread Taylor Swift via swift-evolution
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?

2017-08-03 Thread Taylor Swift via swift-evolution
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?

2017-08-03 Thread Taylor Swift via swift-evolution
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?

2017-08-09 Thread Taylor Swift via swift-evolution
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

2017-08-09 Thread Taylor Swift via swift-evolution
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

2017-08-12 Thread Taylor Swift via swift-evolution
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

2017-08-12 Thread Taylor Swift via swift-evolution
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

2017-07-13 Thread Taylor Swift via swift-evolution
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

2017-07-13 Thread Taylor Swift via swift-evolution
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

2017-07-13 Thread Taylor Swift via swift-evolution
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

2017-07-13 Thread Taylor Swift via swift-evolution
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

2017-07-13 Thread Taylor Swift via swift-evolution
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

2017-07-12 Thread Taylor Swift via swift-evolution
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

2017-07-14 Thread Taylor Swift via swift-evolution
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

2017-07-14 Thread Taylor Swift via swift-evolution
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

2017-07-14 Thread Taylor Swift via swift-evolution
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

2017-07-17 Thread Taylor Swift via swift-evolution
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

2017-07-18 Thread Taylor Swift via swift-evolution
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

2017-07-18 Thread Taylor Swift via swift-evolution
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

2017-07-18 Thread Taylor Swift via swift-evolution
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

2017-07-18 Thread Taylor Swift via swift-evolution
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

2017-07-19 Thread Taylor Swift via swift-evolution
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

2017-07-18 Thread Taylor Swift via swift-evolution
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

2017-07-22 Thread Taylor Swift via swift-evolution
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

2017-07-25 Thread Taylor Swift via swift-evolution
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

2017-07-25 Thread Taylor Swift via swift-evolution
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

2017-07-25 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-23 Thread Taylor Swift via swift-evolution
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

2017-07-19 Thread Taylor Swift via swift-evolution
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.

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

2017-07-19 Thread Taylor Swift via swift-evolution
tly > identifying the pain 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 T

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

2017-07-20 Thread Taylor Swift via swift-evolution
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

2017-07-12 Thread Taylor Swift via swift-evolution
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

2017-07-12 Thread Taylor Swift via swift-evolution
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

2017-07-12 Thread Taylor Swift via swift-evolution
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?

2017-08-04 Thread Taylor Swift via swift-evolution
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?

2017-08-04 Thread Taylor Swift via swift-evolution
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 ... }

2017-07-28 Thread Taylor Swift via swift-evolution
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

2017-08-08 Thread Taylor Swift via swift-evolution
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)

2017-08-08 Thread Taylor Swift via swift-evolution
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

2017-08-08 Thread Taylor Swift via swift-evolution
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?

2017-08-08 Thread Taylor Swift via swift-evolution
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?

2017-08-09 Thread Taylor Swift via swift-evolution
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

2017-08-09 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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.

2017-07-31 Thread Taylor Swift via swift-evolution
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?

2017-07-31 Thread Taylor Swift via swift-evolution
) -> 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.

2017-07-31 Thread Taylor Swift via swift-evolution
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.

2017-07-31 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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?

2017-08-01 Thread Taylor Swift via swift-evolution
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] [Proposal] Explicit Non-Default-Implemented Protocol Requirements

2017-08-02 Thread Taylor Swift via swift-evolution
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”

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

2017-08-02 Thread Taylor Swift via swift-evolution
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

2017-08-02 Thread Taylor Swift via swift-evolution
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

2017-08-02 Thread Taylor Swift via swift-evolution
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

2017-08-08 Thread Taylor Swift via swift-evolution
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?

2017-08-09 Thread Taylor Swift via swift-evolution
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

2017-08-04 Thread Taylor Swift via swift-evolution
: > > 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)

2017-08-07 Thread Taylor Swift via swift-evolution
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)`

2017-08-18 Thread Taylor Swift via swift-evolution
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)

2017-08-17 Thread Taylor Swift via swift-evolution
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)

2017-08-17 Thread Taylor Swift via swift-evolution
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)

2017-08-17 Thread Taylor Swift via swift-evolution
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

2017-08-18 Thread Taylor Swift via swift-evolution
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)

2017-08-18 Thread Taylor Swift via swift-evolution
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)

2017-08-17 Thread Taylor Swift via swift-evolution
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)

2017-08-17 Thread Taylor Swift via swift-evolution
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

2017-08-19 Thread Taylor Swift via swift-evolution
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

2017-08-19 Thread Taylor Swift via swift-evolution
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

2017-08-19 Thread Taylor Swift via swift-evolution
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

2017-08-19 Thread Taylor Swift via swift-evolution
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

2017-08-19 Thread Taylor Swift via swift-evolution
, 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

2017-08-19 Thread Taylor Swift via swift-evolution
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

2017-08-19 Thread Taylor Swift via swift-evolution
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

2017-08-20 Thread Taylor Swift via swift-evolution
, 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

2017-08-20 Thread Taylor Swift via swift-evolution
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

2017-08-20 Thread Taylor Swift via swift-evolution
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:)

  1   2   >