Re: [swift-evolution] [Proposal] Safer half-open range operator

> On Apr 11, 2016, at 12:30 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 11 2016, Haravikk wrote: > >> I like the idea in theory, but the question is; is it really safer to return >> a >> result that the developer may

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

>> If these types are for implementation sharing, should they be >> underscored to discourage their use? Or is the position they occupy in >> the type hierarchy important because Range and ClosedRange will >> eventually occupy them? > > Underscoring hides names from users completely, and IMO that

Re: [swift-evolution] SE-0028 Debugging Identifier #filename

This was already brought up on list. See: [Pitch] Introducing #fileName debug identifier. Module-relative path seems to be most highly requested form of #file. Chris Lattner had the final word, "In this case, I don’t think that more is better. Having too many options and knobs is not good

Re: [swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

> On Apr 11, 2016, at 4:32 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 11 2016, Russ Bishop wrote: > >> Wouldn’t this be the responsibility of UIKit/AppKit teams to provide >> extensions >> that pass the default

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On Apr 11, 2016, at 6:49 PM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 11 2016, Ross O'Brien wrote: > >> I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly >> 'iterate' rather than 'loop'?) > >

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 11 2016, Dave Abrahams wrote: > Thanks for your comments, Brent! > > on Sun Apr 10 2016, Brent Royal-Gordon wrote: > >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md >>

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Ross O'Brien wrote: > I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly > 'iterate' rather than 'loop'?) Maybe 'iterations'. It should be a noun, I think. > I've not missed the C-style for-loop so I've not argued to keep

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 11:41 , Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 11 2016, Charles Srstka > wrote: > >>On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution >>

Re: [swift-evolution] [Proposal] Safer half-open range operator

The idea of having a new operator following the principles of overflow operators looks great. Two distinct operators doing implicit and explicitly might really be a good way to go; it would be concise and wouldn't look like some magic happened behind the scenes. I'd like to hear more opinions

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I think I'd like to +1 a 'for x in loop(from: while: next:)'. (Possibly 'iterate' rather than 'loop'?) I've not missed the C-style for-loop so I've not argued to keep it, but recently I was refactoring a function which started with a UIView and iterated up the hierarchy through the superview

Re: [swift-evolution] [Pre-Draft] Nil-coalescing and errors

Hi. Decoding a JSON is just an example. As I replied to Thorsten, we can think about various cases we want to unwrap multiple optionals at once. This is another example (with the notation `|?` and the postfix version I proposed instead of the infix `???`). ``` do { let sum = try

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Michel Fortin wrote: > Le 11 avr. 2016 à 14:36, Dave Abrahams a écrit : > >> 3. The fact that we're migrating C-style for loops to >> uses of stride, as noted in https://github.com/apple/swift/pull/2125, >> has convinced me that, sadly, we may need

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > On Mon, Apr 11, 2016 at 11:56 AM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > > > Doug wrote this in the Completing Generics

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

On Mon, Apr 11, 2016 at 11:56 AM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > > > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > > > > *Arbitrary

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Le 11 avr. 2016 à 14:36, Dave Abrahams a écrit : > 3. The fact that we're migrating C-style for loops to > uses of stride, as noted in https://github.com/apple/swift/pull/2125, > has convinced me that, sadly, we may need an answer that doesn't > involve ranges. But

Re: [swift-evolution] Requesting default values for Cocoa/Cocoa Touch APIs

Wouldn’t this be the responsibility of UIKit/AppKit teams to provide extensions that pass the default values? Russ > On Apr 8, 2016, at 10:40 AM, Erica Sadun via swift-evolution > wrote: > > Is there a best way to request default values for common Cocoa and Cocoa

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

Fair enough. If we go this direction, there's little sense in conforming StrideTo and friends to Collection at the moment, I suppose? On Mon, Apr 11, 2016 at 9:56 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Xiaodi Wu

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

on Mon Apr 11 2016, Xiaodi Wu wrote: > I realize what follows is actually an argument for restricting stride to > collections with randomly accessible elements, and maybe we should: > > We've touched a little bit on performance, and I think my feeling with stride >

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

on Mon Apr 11 2016, Taras Zakharko wrote: > Hi, > > I think it depends on how expensive the indexed access is on the collection. I > use it primarily on arrays, where self[i] essentially boils down to a pointer > dereference, so I expect the generated code to be very

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

I realize what follows is actually an argument for restricting stride to collections with randomly accessible elements, and maybe we should: We've touched a little bit on performance, and I think my feeling with stride is that just the name itself suggests a certain logic--namely, that we

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 1:01 PM Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > > Compared to this: > > > > collection.index(5, stepsFrom: i) > > > > I would prefer any of these (ordered from least favorite to most): > > > > collection.index(distance: 5,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

I won’t do a full review because I don’t think I have spent enough time reading through the discussion, but just reading the proposal I’d say I’m an huge proponent of this change. Irrespective of the performance benefits, I think it’s a massive win for an easily understandable mental model.

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 11 2016, Joe Groff wrote: >> • Because Swift is unable to express conditional protocol > conformances, implementing this change has required us to create a > great deal of complexity in the standard library API. Aside from the > two excess “Countable” range

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

> On 11 Apr 2016, at 20:47, Taras Zakharko > wrote: > > the question is what is faster: {self[0] < self[1]} or {$1.0 < $1.1} Yes, you are right that this is in fact not obvious! I’ve just measured and, though my implementation is faster,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 11 2016, Stephen Canon wrote: > Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular > (i.e. > follows the usual declension rule for plurals); there’s tradeoffs each way, > but > using the regular plural might make it more familiar

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Thanks for your comments, Brent! on Sun Apr 10 2016, Brent Royal-Gordon wrote: >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md > > Some questions and comments: > >> • Two for ranges that

Re: [swift-evolution] [SR-933] Rename flatten to flattened

>> Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, >> and `foo.tangented`? > > sine, cosine etc. are all nouns so I think as computed properties they’d be > fine as is? So you would favor these? _ = number.sine() _ = number.cosine() _ =

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Sun Apr 10 2016, Jacob Bandes-Storch wrote: > Minor questions after initial read-through: > > - Should the comment on {index,formIndex}(_:stepsFrom:) say what happens if > the > resulting index would be out of bounds? I don't think we should ever specify what

Re: [swift-evolution] [Proposal] Safer half-open range operator

on Mon Apr 11 2016, Haravikk wrote: > I like the idea in theory, but the question is; is it really safer to return a > result that the developer may not have wanted, versus an error indicating > that a > mistake may have been made? That's exactly the question.

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi Taras, > On 11 Apr 2016, at 19:38, Taras Zakharko > wrote: > > Your version might be faster for collection with expensive element access, > but it should be slower for arrays and the like, as it involves additional > intermediate

Re: [swift-evolution] [swift-users] Replacement for NSNumber?

on Mon Apr 11 2016, Ross O'Brien wrote: > Your pointing to two mutually exclusive protocols proves the point. If I want > to > write a generic function for a numerical type which can be added, I can't just > require that the type conforms to IntegerArithmeticType

Re: [swift-evolution] divisible-by operator

> On 11 Apr 2016, at 02:39, Jacob Bandes-Storch wrote: > > I'm not suggesting this for the standard library (or anyone's production > code), but it's fun to note that there is actually a standard mathematical > notation for this, and it has a corresponding Unicode

Re: [swift-evolution] [Completing Generics] Arbitrary requirements in protocols

on Mon Apr 11 2016, Jacob Bandes-Storch wrote: > Doug wrote this in the Completing Generics manifesto, under "Minor > extensions": > > *Arbitrary requirements in protocols > > Currently, a new protocol can inherit from other protocols, introduce new >

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

on Mon Apr 11 2016, Charles Srstka wrote: > On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > > On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution > >

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi, I think it depends on how expensive the indexed access is on the collection. I use it primarily on arrays, where self[i] essentially boils down to a pointer dereference, so I expect the generated code to be very efficient. Your version might be faster for collection with expensive element

Re: [swift-evolution] [Proposal] Add .order() family of methods to Collection

Hi Taras, > On 11 Apr 2016, at 08:48, Taras Zakharko via swift-evolution > wrote: > > The implementation should be fairly straightforward. E.g. here is an > extension method I use: > > extension CollectionType { > func order(@noescape isOrderedBefore:

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > on Sun Apr 10 2016, Dietmar Planitzer > wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>>

Re: [swift-evolution] [SR-933] Rename flatten to flattened

on Sun Apr 10 2016, Arsen Gasparyan wrote: > Ok. Is it final decision? No, any API change needs to go through review on the evolution list. Also, FWIW, I am not particularly keen on changing these names. > Can I start working on it? > > On Sun, 10 Apr 2016 at 23:07, Howard Lovatt via

Re: [swift-evolution] [swift-build-dev] [Review] SE-0063: SwiftPM System Module Search Paths

>> The one thing I feel the proposal lacks currently is how tag versioning >> information in the Swift package is going to correspond to the underlying >> system package. My expectation is that we probably want Swift system >> packages to try and adopt a versioning scheme which matches that of

Re: [swift-evolution] [swift-build-dev] [Review] SE-0063: SwiftPM System Module Search Paths

> The one thing I feel the proposal lacks currently is how tag versioning > information in the Swift package is going to correspond to the underlying > system package. My expectation is that we probably want Swift system packages > to try and adopt a versioning scheme which matches that of the

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

I think we have the following asks: - support methods on a protocol that may or may not be implemented by a confirming type - support statically (per type) detection of whether one of these methods have been implemented so that you can have consistent behavior while interacting with a

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> • Because Swift is unable to express conditional protocol conformances, > implementing this change has required us to create a great deal of complexity > in the standard library API. Aside from the two excess “Countable” range > types, there are new overloads for slicing and twelve

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: > > >> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >> wrote: >> >> One could perhaps work around (a), (b), and (d) by allowing

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution > wrote: > > One could perhaps work around (a), (b), and (d) by allowing compound > (function-like) names like tableView(_:viewFor:row:) for properties, and work > around (c) by allowing a method to

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

Sent from my iPad > On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>> >>> >>>

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Joe’s isn’t saying that “Indexes” is more common, rather that it’s regular (i.e. follows the usual declension rule for plurals); there’s tradeoffs each way, but using the regular plural might make it more familiar for some non-native speakers/readers. – Steve > On Apr 11, 2016, at 9:42 AM,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Thank you Dmitri! > Le 11 avr. 2016 à 18:22, Dmitri Gribenko a écrit : > >> On Mon, Apr 11, 2016 at 9:20 AM, Dmitri Gribenko wrote: >> Hi, >> >>> On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué >>> wrote: >>> Will it still

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

I disagree. According to both http://grammarist.com/usage/indexes-indices/ and http://www.worldwidewords.org/qa/qa-ind2.htm, "indices" is more common in the English-speaking world (outside of parts of America and Canada) as well as in technical contexts. On Mon, Apr 11, 2016 at 12:29 PM, Joe

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

I love irregular plurals as much as the next grammar nerd, but I think it'd be better to use the more regular, but still correct, plural "indexes" rather than "indices". -Joe > On Apr 10, 2016, at 2:41 PM, Chris Lattner via swift-evolution > wrote: > > Hello Swift

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 11, 2016 at 9:20 AM, Dmitri Gribenko wrote: > Hi, > > On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué > wrote: >> Will it still be possible with the new protocol and types? Especially, how >> to I generate "BETWEEN 0 AND 17" from 0..<18

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Hi, On Mon, Apr 11, 2016 at 9:16 AM, Gwendal Roué wrote: > Will it still be possible with the new protocol and types? Especially, how to > I generate "BETWEEN 0 AND 17" from 0..<18 without a supporting collection > that gives me the predecessor of 18? You would

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Hello, I have a user question regarding the proposed range types that replace the old range/interval. The old hierachy allowed me to turn ranges to SQL expressions through the following mapping (see

Re: [swift-evolution] [swift-users] Replacement for NSNumber?

This comes up often enough that we should probably write it somewhere, but we don't have this protocol for the simple reason that there are very few algorithms that are correct for both integers and floating-point numbers. Even something as simple as "average" needs to be handled differently.

Re: [swift-evolution] [swift-users] Replacement for NSNumber?

Your pointing to two mutually exclusive protocols proves the point. If I want to write a generic function for a numerical type which can be added, I can't just require that the type conforms to IntegerArithmeticType because that excludes all the floating point types. Protocols for various

Re: [swift-evolution] [swift-users] Replacement for NSNumber?

> It’s inconvenient that structs can’t inherit, and so things like Int and > Double aren’t known as numbers. Should there be a Number protocol that > encompasses all things number-like? Taje a look at the IntegerType and FloatingPointType -- Joanna Carter Carter Consulting (de mon iPhone)

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0065 A New Model for Collections and Indices

> On Apr 10, 2016, at 2:41 PM, Chris Lattner wrote: > > The review of "A New Model for Collections and Indices" begins now and runs > through April 18th. The proposal is available here: > > >

Re: [swift-evolution] [Proposal] Safer half-open range operator

I like the idea in theory, but the question is; is it really safer to return a result that the developer may not have wanted, versus an error indicating that a mistake may have been made? I wonder if perhaps there could be an alternative, such as a variation of the operator like so:

[swift-evolution] [Proposal] Safer half-open range operator

This proposal seeks to provide a safer ..< (aka half-open range operator) in order to avoid **Array index out of range** errors in execution time. Here is my first draft for this proposal:

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

> * What is your evaluation of the proposal? +1. I think it makes the collection model more simple and more flexible at the same time. By coupling index to a specific collection, rather then treating it as a separate, independent entity, we can more easily implement alternative

Re: [swift-evolution] [SR-933] Rename flatten to flattened

I think current -ed/-ing convention is very ugly. It breaks syntactic correctness, experience from other languages, mathematical notation and functional idioms. `InPlace` suffix was so far more correct in these terms. We can make anything a convention, but should we? I liked the proposal about

Re: [swift-evolution] [Idea] How to eliminate 'optional' protocol requirements

> And “optional” disappears from the language. Now, there’s no optionality > left, so our useDelegate example tries to just do correct calls: > > func useDelegate(delegate: NSTableViewDelegate) -> NSView? { > let view = delegate.tableView(tableView, viewFor: column, row: row) > let height =

Re: [swift-evolution] [SR-933] Rename flatten to flattened

> On 10 Apr 2016, at 22:11, Brent Royal-Gordon wrote: > > Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, and > `foo.tangented`? sine, cosine etc. are all nouns so I think as computed properties they’d be fine as is? > If there is a

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

ah, you're right about that! somehow there was a doubly linked list in my head, sorry. TedvG > On 11 Apr 2016, at 11:20, Haravikk wrote: > > >>> On 10 Apr 2016, at 22:44, Ted F.A. van Gaalen via swift-evolution >>> wrote: >>> >>> Say

Re: [swift-evolution] [Draft]: Introducing a striding(by:) method on 3.0 ranges

> On 10 Apr 2016, at 22:44, Ted F.A. van Gaalen via swift-evolution > wrote: > >> Say you wanted to stride through a singly-linked list, it would actually be >> beneficial to support only forward strides, the same is true of sequences, >> as you either may not know

Re: [swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

> On 11 Apr 2016, at 10:05, Jacob Bandes-Storch wrote: > > Clarifying questions as comments: > > guard device = MTLCreateSystemDefaultDevice() else { > fatalError() > } > device = nil // Is this still allowed here? Device instance variable is not an

Re: [swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

Clarifying questions as comments: guard device = MTLCreateSystemDefaultDevice() else { fatalError() } device = nil *// Is this still allowed here?* device.newDefaultLibrary() *// Is this allowed without optional chaining?* Also, I don't see any reason this idea should

[swift-evolution] [Completing Generics] Arbitrary requirements in protocols

Doug wrote this in the Completing Generics manifesto, under "Minor extensions": > **Arbitrary requirements in protocols* Currently, a new protocol can inherit from other protocols, introduce new > associated types, and add new conformance constraints to associated types > (by redeclaring an

Re: [swift-evolution] Proposal: disallow nil in favor of .None

Please not!! If this was an April 1 joke, it's too late. Von: Paul Young Betreff: [swift-evolution] Proposal: disallow nil in favor of .None Datum: 10. April 2016 22:53:18 MESZ An: "swift-evolution@swift.org" Please forgive me if this

[swift-evolution] [Proposal] Add .order() family of methods to Collection

Swift standard library already offers a useful set of sort() functions. However, it is also often useful to know how the collection should be rearranged in order to become sorted. For example, R defines the order() function which returns a permutation of collection indexes which rearrange the

[swift-evolution] [Proposal] Allow optional binding of instance variables in constructors

One place where I find myself using the guard statement a lot is state initialisation. E.g. in init() guard let device = MTLCreateSystemDefaultDevice(), library = device.newDefaultLibrary() else { fatalError(“Could not initiallize Metal, aborting”) } Here, the two

Re: [swift-evolution] [Proposal] Factory Initializers

At first, I was opposed to this idea but after working with many heterogeneous implementations of the same protocol, where instance creation needs to be dynamically dispatched to based on the properties of the data, I think that factory initialisers might be a nice idea. However, it would IMO

Re: [swift-evolution] [Proposal] Factory Initializers

I thought this already went in review somehow, sorry a +1 from me as well. [[iOS messageWithData:ideas] broadcast] > On 10 Apr 2016, at 19:14, Radosław Pietruszewski via swift-evolution > wrote: > > Nice! > > I must admit, my first reaction to this proposal was

Re: [swift-evolution] [Idea] Allow more operators as custom operators

Thank you Brent! I forgot about the cases you described, where use of `->`, `!` or `?` cannot be expressed as operator functions. The question is closed now, I guess. - Anton 2016-04-11 9:03 GMT+03:00 Brent Royal-Gordon : > > `->`, `?` and `!` are used in types, but they

Re: [swift-evolution] [SR-933] Rename flatten to flattened

Totally agree with Brent, map/flatMap are terms of art. Sent from my iPad On 10 Apr 2016, at 23:11, Brent Royal-Gordon via swift-evolution wrote: >> I still don’t see what’s being lost here, it’s not like the proposal is to >> radically rename them, all we’d end up

Re: [swift-evolution] [Idea] Allow more operators as custom operators

> `->`, `?` and `!` are used in types, but they are mostly unambiguous in > expressions. Sure, but types can appear in the middle of expressions. If we drop the `.self` requirement, a type name will *be* an expression. I don't think you can just ignore type names. > The only use of `!` in