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

Just as note, i think the sintax should be: 0...9 0..<9 0>..9 0>.<9 Because the intention is produce a number bigger than 0 (start). So greater than zero less than nine. Em sex, 8 de abr de 2016 22:50, Michel Fortin via swift-evolution < swift-evolution@swift.org> escreveu: > Le 8 avr. 2016

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

> (tl;dr: will Swift 3.0 improve iteration for enum values? Some kind of > .next() method for values or .all[] property. Currently we have a problem > with this.) There are proposals to do this, but they're on hold at the moment because the guy who was the main driving force got busy with

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

Le 8 avr. 2016 à 14:37, Erica Sadun via swift-evolution a écrit : > > (0 ... 9).striding(by: -2) == [9, 7, 5, 3, 1] The above reads wrong to me. The expression has to be read differently depending on the tinny detail that is the sign of the step that comes last: *

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

Thanks Brent -- I completely agree with your assessment. I was failing to come up with the proper argument for just about the same idea! Guillaume Lessard > On 8 avr. 2016, at 18:32, Brent Royal-Gordon via swift-evolution > wrote: > >> The 'flatten()' method didn't

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

> The 'flatten()' method didn't get the Swift 3 API renaming treatment it > should have, to go along with reversed, sorted, joined, etc. > As I see Dmitri Gribenko already agree with it but we still have to discuss > it here. So what do you think? I'm in favor. Though all of these things are

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

> We propose to introduce a striding(by:) method on the revised 3.0 Range type. I take it that we're taking an incremental approach here, and further steps like: * Adding new range operators * Making all collections Strideable * Unifying Range and IntervalType so we can stride over non-integers

Re: [swift-evolution] [Pitch] Add namespacing to associatedTypes

I agree with Brent that there is a larger issue to solve, but I would still like to hear your solution, as it may inform the larger solution (and this may be a starting point to tackling the whole thing). The thing that makes the most sense to me, off the top of my head, is to have an error

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

I am agnostic on a .striding() method, but I am strongly agains any suggestions of removing/replacing the global stride() function. The stride function does not pollute the global namespace as it is a universally useful construct (among others, for implementing classical iterating for loops),

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

Would this still be an issue if switch statements were less verbose? I don't see why a "switch" statements should be so much more verbose than an "if statement". Writing boiler plate for switch statements is by far my #1 irritation at the moment (now that argument labels have been made beautiful

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

> On Mar 23, 2016, at 5:13 AM, Brent Royal-Gordon via swift-evolution > wrote: > > * Allow you to attach member definitions to particular cases. It would be an > error if they didn't all define the same members, unless there was a > top-level catchall. > >enum

Re: [swift-evolution] [Proposal] Custom operators

Based on commit ‘01317e1a’: I think that it makes sense for membership to live outside of a precedence group. An example is if I wanted to add a new assignment operator ( maybe ??= 'assign if nil’), I would want it to have the same precedence as existing assignment operators, including

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

> On Apr 8, 2016, at 4:19 AM, Haravikk via swift-evolution > wrote: > If we want mutating forms of this methods then I much prefer .map() and > .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts > the naming convention used everywhere

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

Draft here: https://gist.github.com/erica/a51a981ee0352235204692affa959307 Feedback solicited, both positive and negative. We've also got a related proposal about expanding ranges, which you can look at here

Re: [swift-evolution] Shortcut for creating arrays

on Fri Apr 08 2016, Arsen Gasparyan wrote: > I want to find a conciseness and simplicity solution. But > componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet()) > scares > me :) Yes, we should have words.split() at some point. IMO this is in scope

Re: [swift-evolution] Feature proposal: Range operator with step

on Fri Apr 08 2016, Erica Sadun wrote: >> On Apr 6, 2016, at 3:32 PM, Dave Abrahams wrote: >> >> >> on Wed Apr 06 2016, Erica Sadun wrote: >> > >>>On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: >>> >>>These

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

on Fri Apr 08 2016, Pyry Jahkola wrote: > On 08 Apr 2016, at 13:19, Haravikk via swift-evolution > wrote: > > I think it makes sense to just rename them; it’s not as though flattened > or > mapped is somehow far removed

Re: [swift-evolution] Limit checking syntax

on Fri Apr 08 2016, "Vladimir.S via swift-evolution" wrote: > On 08.04.2016 4:14, Harlan Haskins via swift-evolution wrote: >> I’ve found that .contains works well for all my uses. >> >> (0..<100).contains(x) > > Hmm.. Isn't next construction is much more readable?:

Re: [swift-evolution] [Idea] Find alternatives to `switch self`

I much prefer the Java style of enums, which are essentially classes limited to a fixed set of instances. In Java, Suit would look like this: public enum Suit { Hearts("♥", true), Spades("♠", false), Diamonds("♦", true), Clubs("♣", false); String description; boolean isRed;

Re: [swift-evolution] Feature proposal: Range operator with step

> On Apr 6, 2016, at 3:32 PM, Dave Abrahams wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: >> >>These all look reasonable to me. >> >>Lastly, if you want the positive stride

Re: [swift-evolution] [Review] SE-0059: Update API Naming Guidelines and Rewrite Set APIs Accordingly

on Thu Apr 07 2016, Xiaodi Wu wrote: > If we're going to bikeshed again: how about "assign"? It begs for a preposition, which is usually “to,” which has the wrong meaning :( > On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution > wrote: > >

Re: [swift-evolution] Shortcut for creating arrays

I would create a computed property on String and call it "words" Tino ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal] Custom operators

Right, `infix` operators without a precedence group logically should be able to be used, just with parentheses everywhere. But users will most likely want to use such operators with `=` without parentheses. It means, such operators should still belong to some precedence groups. I suggest that

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

Is there a best way to request default values for common Cocoa and Cocoa Touch APIs? Now that we're moving to Swift, the language supports defaults and omitted parameters but the ObjC APIs do not (yet) supply them. For example, dismissViewControllerAnimated(flag: true, completion: nil) could

Re: [swift-evolution] [Proposal] Custom operators

If I want to define a new operator, it seems like an unnecessary overhead to have to immediately decide which precedence group it should belong to before it can be used (assuming it doesn't interact with other operators). At the moment, new operators are implicitly assigned a 'default' precedence

Re: [swift-evolution] Shortcut for creating arrays

As I understand in initial message, string should be splitted by spaces, not all kind of whitespaces(like TAB). whiteCharacterSet() is not just space(at least TAB char there too). So, if we need split just by space we need some componentsSeparatedBySpaceCharacter(). And IMO this is not a good

Re: [swift-evolution] [Proposal] Custom operators

Thank you for your reply, Chris! I was thinking about purging directives from the proposal, and that was what I needed to do it. So, the proposal is now completely overhauled: https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md Yes, Maximilian

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

My main point was that, this was an extremely common practice in Objective C (one which was even used/encouraged by Apple for quite a while) and the proposal needs to address it. There is a lot of working code out there that uses this pattern. In short, we need to be careful not to

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

On Fri, Apr 8, 2016 at 3:49 AM, Vladimir.S wrote: > > > On 07.04.2016 21:43, Dmitri Gribenko wrote: >> >> There would be no need to. Collection will have a .successor(of:) >> method that returns the next index after the given one. >> > > I see. Thank you for letting know about

Re: [swift-evolution] [Discussion] Difference between static and lazy variables regarding evaluation of closure

Yes, IMO it really looks strange. Just checked: class Foo { static var test = "test" static var bar: String = { print("static") return "Default" }() lazy var baz: String = { print("lazy") return "Lazy"

Re: [swift-evolution] Shortcut for creating arrays

I want to find a conciseness and simplicity solution. But componentsSeparatedByCharactersInSet(NSCharacterSet.whiteCharacterSet()) scares me :) On Fri, Apr 8, 2016 at 7:39 PM James Campbell wrote: > Exactly > > Sent from Supmenow.com > > > > > On Fri,

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

I want to reiterate that I have objective-c code, others have objc code, and the cocoa, etc. frameworks have code that depend on optional protocol for things like (but not limited to) delegates. This is of course obvious but what seems to get lost in the discussion is that you can't always replace

Re: [swift-evolution] [Review] SE-0062: Referencing Objective-C key-paths

> What is your evaluation of the proposal? I like it and think it’s something Swift should definitely have. A quibble: I think there’d be value in also having: #key(ClassName.propertyName) …which is the same as `#keyPath`, but without support for *paths*. It’s functionally-redundant with

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

Table view semantics were discussed at length on a prior version of the thread. That pattern is less than ideal; it essentially creates magic behavior that's only described by documentation… or, worse, completely forgotten about in documentation; something changing from version to version of the

Re: [swift-evolution] Ability to pack, order and align certain types of Structs (like in C)

Chris, Thanks for supporting it in principle. I understand that it is out of scope for Swift 3 and that using C is one of the only decent workarounds at the moment. However, since you concur with what is being requested, would it be OK to: (a) Draft a summary proposal and commit it to the

Re: [swift-evolution] Shortcut for creating arrays

On 08.04.2016 17:05, Ross O'Brien via swift-evolution wrote: Well, you can do this already: let words = "rats live on no evil star".componentsSeparatedByString(" ") so I don't know how much a shortcut is needed. Also thought about componentsSeparatedByString, clearly says what we have, what

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

Am 08.04.2016 um 11:59 schrieb Brent Royal-Gordon : >> I only wonder whether you really want to repeat Error() all over, possibly >> with `aString` etc. as argument. > > `Error()`, no. `SpimsterKitError.invalidWicketField("a"`), yes, because even > if `Int.init(_:)`

Re: [swift-evolution] Shortcut for creating arrays

Pehaps we could have a function that splits by whitespace. "h j c k".split() *___* *James⎥Alex's Minder* *ja...@supmenow.com ⎥supmenow.com * *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On 8 April

Re: [swift-evolution] Shortcut for creating arrays

Well, you can do this already: let words = "rats live on no evil star".componentsSeparatedByString(" ") so I don't know how much a shortcut is needed. And given '%w' would currently be impossible in Swift as an operator containing a letter, is there a Swiftier function name or operator for this?

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

> On 8 Apr 2016, at 12:00, Pyry Jahkola wrote: > > >> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution >> > wrote: >> >> I think it makes sense to just rename them; it’s not as though flattened or >>

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

> On 8 Apr 2016, at 11:32, Brent Royal-Gordon wrote: > >> Can someone fill me in as to how this differs from (0…4).contains(x)? >> >> Personally I don’t like the choice for the operator, and think it’s not very >> clear, if we can do the same thing with a method then

[swift-evolution] Shortcut for creating arrays

Hey guys, Very often we need to create an array strings. It's a routine task and I really like shortcut in Ruby that shortcut makes everyday coding a little bit easier and fun: words = %w[rats live on no evil star] What do you think about adding something like this in Swift? Cheers, Arsen

Re: [swift-evolution] [Proposal] Custom operators

On 4/8/16 02:59, Chris Lattner via swift-evolution wrote: >> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution >> wrote: >> Link for newcomers: >> https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0064: Referencing the Objective-C selector of property getters and setters

> What is your evaluation of the proposal? +1 > Is the problem being addressed significant enough to warrant a change to > Swift? Yes. I agree with Michael Buckley that this feels more like an oversight in SE-0022 rather than a completely new thing. > Does this proposal fit well with the feel

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

> On 08 Apr 2016, at 13:19, Haravikk via swift-evolution > wrote: > > I think it makes sense to just rename them; it’s not as though flattened or > mapped is somehow far removed from the original meaning as the actual action > is the same, it’s just changing tense.

Re: [swift-evolution] Improvement proposal: change overflow behavior in successor()/predecessor() methods for Int types

On 07.04.2016 21:43, Dmitri Gribenko wrote: There would be no need to. Collection will have a .successor(of:) method that returns the next index after the given one. I see. Thank you for letting know about this. I can see that, but when you know that you are dealing with an integer,

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

> Can someone fill me in as to how this differs from (0…4).contains(x)? > > Personally I don’t like the choice for the operator, and think it’s not very > clear, if we can do the same thing with a method then I’d prefer removing the > operator to be honest. ~= is the way you customize how a

Re: [swift-evolution] [Proposal] Invert the order of pattern match operator

Can someone fill me in as to how this differs from (0…4).contains(x)? Personally I don’t like the choice for the operator, and think it’s not very clear, if we can do the same thing with a method then I’d prefer removing the operator to be honest. > On 7 Apr 2016, at 12:57, David Rodrigues via

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

> On 7 Apr 2016, at 19:12, Dave Abrahams via swift-evolution > wrote: > > We kept flatten as is because it is part of a suite of methods that are terms > of art from functional programming (map, filter, flatMap, reduce) that don't > follow the naming guidelines I

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

> I only wonder whether you really want to repeat Error() all over, possibly > with `aString` etc. as argument. `Error()`, no. `SpimsterKitError.invalidWicketField("a"`), yes, because even if `Int.init(_:)` threw *an* error, it wouldn't throw *your* error. -- Brent Royal-Gordon Architechies

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

___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Feature proposal: Range operator with step

> At the risk of asking one of those newbie questions, why bother with StrideTo > and StrideThrough? Isn't a Generator or Array more to the point? You don't want to return an Array because you want to generate the values lazily. If `stride(over: 1..<1_000_000, by: 10)` returned an Array, you

Re: [swift-evolution] Limit checking syntax

___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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

Proposal sounds nice, but shouldn't it go hand in hand with the review of dispatching rules for protocol extensions (i.e.: dynamic dispatch by default unless overridden by a user declaration/annotation or when the compiler is sure no side effects will occur... ProtocolA and

Re: [swift-evolution] My personal beef with leading-dot syntax

> On Apr 6, 2016, at 9:27 AM, Jordan Rose via swift-evolution > wrote: > > >> On Apr 5, 2016, at 0:55 , Radosław Pietruszewski via swift-evolution >> wrote: >> >> As others noted: >> >> * the ability to say .min, .max, .blackColor(),

[swift-evolution] [Discussion] Deprecation Linking

I work on an API and like any API, we frequently deprecate methods (more than we would like). I think would be useful, when you deprecate something there is a link from the old method to the new method(s). With this facility it would be possible to match the old parameter name with the new

Re: [swift-evolution] [Pitch] Moving where Clauses Out Of Parameter Lists

> On Apr 6, 2016, at 11:30 AM, Developer via swift-evolution > wrote: > > If you've ever gotten to the point where you have a sufficiently generic > interface to a thing and you need to constrain it, possibly in an extension, > maybe for a generic free function or

Re: [swift-evolution] Ability to pack, order and align certain types of Structs (like in C)

> On Apr 7, 2016, at 12:28 PM, hitstergtd+swiftevo--- via swift-evolution > wrote: > > To the community: > > Neither am I a compiler/language design expert nor have I previously > written a proposal to that effect, so I apologise if I have > trivialised the matter

Re: [swift-evolution] [Proposal] Custom operators

> On Apr 7, 2016, at 1:39 PM, Антон Жилин via swift-evolution > wrote: > > First of all, sorry for the delay. I still hope to finish the discussion and > push the proposal to review for Swift 3.0. > Link for newcomers: >