Re: [swift-evolution] superscripts, subscripts, etc.

Going a little further... It’s not hard to imagine a situation where the order of a trailing annotation matters. Ie, that X²₃ is a different thing from X₃². (X squared sub 3 ≠ X sub 3 squared) So i think you’d want an array of trailing annotations and an array of leading annotations, where an

Re: [swift-evolution] A path forward on rationalizing unicode identifiers and operators

> On Oct 4, 2017, at 6:41 AM, Alex Blewitt via swift-evolution > wrote: > >> On 4 Oct 2017, at 11:42, Mike Kluev via swift-evolution >> wrote: >> >> on Tue, 3 Oct 2017 11:00:33 -0600 Dave DeLong >> wrote: >> >>

Re: [swift-evolution] [Proposal] Random Unification

I agree with this. The only app-based use case I can think of for a full-range random value would be to construct a unique temporary file name. But that’s easily replaced with UUID().uuidString or mkstemp() (or whatever it’s called). Dave Sent from my iPhone > On Nov 17, 2017, at 9:10 AM,

Re: [swift-evolution] Proposal: Allow operators to have parameters with default values

> On Nov 3, 2017, at 9:59 PM, Chris Lattner wrote: > > >> On Nov 3, 2017, at 8:40 AM, Dave DeLong via swift-evolution >> wrote: >> >> That’s cool, but a hygienic macro system isn’t anywhere on the Swift roadmap. >> >> Chris has mentioned in

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Hi Jordan, Thanks for your thoughtful reply. Comments inline... Sent from my iPad > On Jan 4, 2018, at 5:37 PM, Jordan Rose wrote: > > Hi, Dave. You're right, all these points are worth addressing. I'm going to > go in sections. > >> This whole “unexpected case” thing

Re: [swift-evolution] [Pitch] #warning

I've used custom warnings and errors in other languages and find them both useful. Forgive my ignorance, but does Swift have warning levels, warning IDs and pragmas/build settings to disable specific warnings? If so, it would be good to specify exactly how this feature interact with those. For

Re: [swift-evolution] [Pitch] Tuple Destructuring in Parameter Lists

This is an interesting proposal, but I think splatting like Python would be preferable: creators of functions use separate parameters and callers can expand tuples as necessary by prefixing a tuple at point of use with * to expand it into separate arguments. Even with the Swift language as it is

Re: [swift-evolution] [Pitch] Allow explicit specialization of generic functions

I have an alternative you might like to consider: type deduction operators The input type deduction operator lets you put one or more types in front of a function to guide type deduction based on the parameters The output type deduction operator lets you put a type after a function to guide type

Re: [swift-evolution] [Pitch] Property reflection

This is important and really useful. There's a lot to like here. I have been thinking about property reflection recently too. Don't have time to write too much on it now, but was wondering what was the thinking behind suggesting an opt-in? For me, I would hope that getting access to a single

Re: [swift-evolution] Ad hoc enums / options

I support the original proposal. My assumption is that (.fit|.fill) is the name of a type that can be used anywhere types can be named. I think the concern about duplicates is misplaced. If the same developer creates the scaleAndCrop function and the rect function, they may decide to extract the

Re: [swift-evolution] [Proposal] Protected Access Level

It might be worth being more specific with your comparison between the "lock and key" access control I described and the other techniques described in this thread. Given that the designers of Swift were familiar with protected access level from other languages and deliberately chose to exclude it,

Re: [swift-evolution] [Draft] Automatically deriving Equatable and Hashable for certain value types

Is there no one that thinks it's sufficient if users can create a tuple from a list of properties and reuse tuple equality and hash? Is there no one that thinks it's sufficient if the system were to supply a named function for comparing two Any's for equality (with reference equality semantics

Re: [swift-evolution] [Proposal] Protected Access Level

Here's demo code for emulating protected in Swift: https://gist.github.com/callionica/19da0763c0b0b4c504fc5f46d07e8ee8 ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Protected Access Level

I can't reply directly to all the points in this thread, but I will just say that there are ways of emulating protected in the language as it exists today: If the goal is to have functions that can be overridden by subclasses without being called by external classes, you can create a parameter of

Re: [swift-evolution] [Proposal] Protected Access Level

I've written up how to provide protected access control for Swift code today here: http://www.callionica.com/developer/#swift-protected No compiler changes necessary for this technique and it distinguishes between methods that can only be overridden and methods that can be both called and

Re: [swift-evolution] Throws? and throws!

One stray thread performing an overflowing addition can be the difference between a secure system and an insecure one. Better to take the process down. -- Callionica On Sun, Jan 15, 2017 at 10:48 PM Russ Bishop via swift-evolution < swift-evolution@swift.org> wrote: > > > I don’t think it makes

Re: [swift-evolution] Pitch: really_is and really_as operators

I used this several months ago for extracting data from Any: // Dynamic cast without bridging func dynamicCast(_ type: T.Type, _ v: Any)->T? { guard let result = v as? T where v.dynamicType is T.Type else { return nil; } return result } from

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

How do you figure unowned pointers help you detect errors? Dangling pointers give you no guarantees. On Wednesday, September 14, 2016, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > Sorry to hijack the thread, but I was working to fix the fact that we > can't have optional

Re: [swift-evolution] Protected Access

For overridable, but not callable, you can use the technique outlined at http://www.callionica.com/developer/#swift-protected (give your method a parameter of a type that only the base class can create) On Friday, October 7, 2016, Jonathan Hull via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] Add something like [unowned self] syntax for passing instance methods into closure parameters without creating retain cycles

er the original instance is strong-released for the last time. I can't > remember if this is enabled in release builds as well; under -Ounchecked > they do become unsafe-unretained. > > Jordan > > > On Sep 14, 2016, at 10:51, Callionica (Swift) via swift-evolution < > swift-e

Re: [swift-evolution] Renaming for Protocol Conformance

C# has this feature (called "explicit interface implementation" or "explicit interface method implementation"). It's useful for implementing multiple data-like interfaces that have common names like Name, ID, Title, and Description. It's useful for keeping public interfaces clean. It's useful for

Re: [swift-evolution] Renaming for Protocol Conformance

The framework design guidelines were for ensuring code consistency and necessarily included stylistic decisions. There was no ban on using explicit interface implementation, just reasonable caution to the end goal of consistency. This is what the framework design guidelines said in 2010:

Re: [swift-evolution] [Proposal draft] Conditional conformances

Interesting comment about worries that you'd be dispatched to the least good SS version . A different language with different constraints, but when LINQ to Objects implementers needed to provide optimized c# implementations for some operations they chose a runtime type check to dispatch to the

Re: [swift-evolution] [Proposal] Type Narrowing

Great. I'd like to see something like this. Couple of comments: You don't explicitly address overload selection. Do you intend it to be affected? Impact on existing code section could be more descriptive. On Thursday, November 3, 2016, Haravikk via swift-evolution < swift-evolution@swift.org>

Re: [swift-evolution] URL Literals

It would be a good idea for literals of different types to be easily recognizable in the source by human readers and extractable from the source by tools. I'm sure everyone agrees that it's annoying/risky when you can't even distinguish localizable strings (user messages) from non-localizable

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

I'm certainly assuming that users have a basic understanding of scope (without that, what would be the intention behind defining the class within the function?). I'm not clear on what you see as the downside of letting classes capture locals for users that are unaware of capturing. On Thu, Dec

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

Assuming capture were allowed, people defining classes within functions who didn't want them to capture could position the class definition prior to any other code in the function so that there would be nothing to capture. On Thu, Dec 22, 2016 at 4:13 PM Xiaodi Wu via swift-evolution <

Re: [swift-evolution] Should we relax restriction on closing over outer scope in class declarations?

I support the principle of progressive disclosure. I still fail to see how if class capture were introduced it would prevent people from learning about classes, functions, closures or any other existing concept in whatever order the student or teacher preferred. I disagree that there is any

[swift-evolution] Fwd: Should we relax restriction on closing over outer scope in class declarations?

t; wrote: On Dec 23, 2016, at 1:10 AM, Callionica (Swift) via swift-evolution < swift-evolution@swift.org> wrote: I'm certainly assuming that users have a basic understanding of scope (without that, what would be the intention behind defining the class within the function?). Despite its

Re: [swift-evolution] Fwd: Should we relax restriction on closing over outer scope in class declarations?

. > > ~Robert Widmann > > 2016/12/24 11:45、Callionica (Swift) via swift-evolution < > swift-evolution@swift.org> のメッセージ: > > Missed swift-evol in my reply > > -- Forwarded message - > From: Callionica (Swift) <swift-callion...@callionica.com

Re: [swift-evolution] Fwd: Should we relax restriction on closing over outer scope in class declarations?

ive because of these implicit captures. It sounds like >> what you want is a member, and I'm not sure it's worth saving 5 lines to >> avoid that fact. >> >> ~Robert Widmann >> >> 2016/12/24 11:45、Callionica (Swift) via swift-evolution < >> swift-evo

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

  1   2   >