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

We will be proposing exactly that which you've put in parentheses, i.e. floating point types will get their own strides, and it will be a precondition failure to try to stride from or to infinity or nan :) On Sun, Apr 10, 2016 at 4:47 AM wrote: > It’s not a matter of

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

+1 for Haravikk's reasoning, mapped etc. are the best choice. On Saturday, 9 April 2016, Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > > On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org > wrote: > > > > `flatten`

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

Oh, right, we’re talking about Swift 3.0… I really need to get that up and running on my computer. > On Apr 9, 2016, at 8:58 PM, Dave Abrahams wrote: > > > on Sat Apr 09 2016, davesweeris-AT-mac.com wrote: > >>On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution

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

It’s not a matter of floating point error accumulation… At least on my machine, once a Double hits +/-∞, there’s no way that I know of to get back to normal floating point numbers. That is to say, for *all* normal, finite values of x, "-Double.infinity + x" will just return “-inf". If x is to

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

Yikes. Not too concerned about the infinite loop issue, as floating point strides when fixed to avoid error accumulation will necessarily enforce a finite number of steps. However, you're talking a regular, not-at-all-lazy Array being returned? That would be not good at all... On Sun, Apr 10,

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

> On Apr 9, 2016, at 5:58 PM, Haravikk via swift-evolution > wrote: > > >> On 9 Apr 2016, at 10:50, Xiaodi Wu > > wrote: >> >> But, ranges are useful for more than just stride, and so I would say it >> doesn't make

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

IMO, 9...0 is a non-starter. Especially with Range taking on the role of Interval, it's critical that they have no direction. Suppose you have two ranges, 0...9 and 9...0. Is 0...9 == 9...0? IMO, two countable ranges r0 and r1 are equal if, for value in r0, r1.contains(value) == true, and vice

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

> On Apr 9, 2016, at 4:33 AM, Haravikk via swift-evolution > wrote: > > While I’m in favour of the basic idea I think the operator selection is too > complex, and I’m not sure about the need for negative strides. Really all I > want are the following: > > (0

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

There's been a little movement on this in the ticket that I opened. Joe Groff suggested the following attribute: @implements(A.T) typealias AT = String @implements(B.T) typealias BT = Int I would prefer a syntax more in line with what you suggested typealias A.T = String typealias B.T = Int

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

> Am 09.04.2016 um 19:43 schrieb Антон Жилин : > [...] > Now, I see only 1 large question/problem risen by David Waite: > Should precedence relationships be defined inside or outside of precedence > groups? > That is: should we be able to add arbitrary relationships

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

> On 9 Apr 2016, at 10:50, Xiaodi Wu wrote: > > But, ranges are useful for more than just stride, and so I would say it > doesn't make sense to have an intrinsic direction for Range, which pointedly > has lowerBound and upperBound but not start and end. For sample, there

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

Le 9 avr. 2016 à 13:23, Xiaodi Wu a écrit : > The sign of the stride size is already (in the current version of Swift) > evaluated in the stride generator/iterator; as written, it is evaluated every > time next() is called, but of course that is optimized away when

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

For a while I've thought it would be useful to have a way to refer to the protocol's default implementation, even when you provide your own. We could possibly do away with most people's concerns and optional methods if we could do something like this: if MyProtocol.someMethod === Self.someMethod

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

Thanks! -Chris > On Apr 9, 2016, at 9:47 AM, hitstergtd+swift...@gmail.com wrote: > > Chris, > > Thanks. The distraction factor makes sense. I will update SR-1134 as > discussed and mark it as post Swift v3. > >> On 9 April 2016 at 14:13, Chris Lattner wrote: >> >> On

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

As always, link to the proposal: https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md Without further ado, I changed syntax for declaring that an operator belongs to a group. It now looks like: infix operator <> : Comparative Next, I added a

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

The sign of the stride size is already (in the current version of Swift) evaluated in the stride generator/iterator; as written, it is evaluated every time next() is called, but of course that is optimized away when possible. What we are proposing adds no additional logic to the loop. I can't see

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

Chris, Thanks. The distraction factor makes sense. I will update SR-1134 as discussed and mark it as post Swift v3. On 9 April 2016 at 14:13, Chris Lattner wrote: > > On Apr 8, 2016, at 8:02 AM, hitstergtd+swiftevo--- via swift-evolution > wrote:

Re: [swift-evolution] Shortcut for creating arrays

FWIW, in Swift 3: “h j c k”.componentsSeparated(by: “”) or “h j c k”.componentsSeparatedByCharacters(in: .whitespace()) which is slightly better. Regarding the proposal, I love Ruby’s %w(foo bar) and other nice shortcuts like that, but short-term I think we have bigger problems in Swift. I

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

Le 9 avr. 2016 à 4:25, Xiaodi Wu a écrit : > Note that it's not possible to write 9...0. Once that is clear, it's > fairly intuitive (IMO) to look to the stride size for indicating the > direction in which we stride, since that is the only other value there > is. I know it's

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. What I really want is the postfix version of `???` as I wrote in my first post in this thread. > Besides the proposed infix `???`, I also want the postfix one which > throws a

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

Thanks for the excellent writeup and thought on this. I strongly believe - as a protocol adaptor - that having the ability to know if a default implementation is provided in the interface I see. It would also be helpful if documentation (header docs) about the characteristics of the default

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

Chris, thanks for commenting, but see below: On 4/9/16 10:33, Chris Lattner via swift-evolution wrote: >> On Apr 8, 2016, at 5:16 AM, Rainer Brockerhoff via swift-evolution >> wrote: >>> - I definitely agree that a partial ordering between precedences is all >>> that

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

> On Apr 9, 2016, at 6:36 AM, Chris Lattner via swift-evolution > wrote: > I do think it is useful to be able to specify precedence relationships > without having to define a “group”, to avoid boilerplate when you have one > operator at a logical level (“??” for

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

On Apr 8, 2016, at 12:28 PM, Антон Жилин wrote: > The question 4 (`prefix operator ! { }` or `prefix operator !`) seems dead > simple, because if we need to declare precedence group in body of infix > operators, then other operators should have it for consistency. > >

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

> On Apr 8, 2016, at 5:16 AM, Rainer Brockerhoff via swift-evolution > wrote: >> - I definitely agree that a partial ordering between precedences is all that >> we need/want, and that unspecified relations should be an error. >> ... >> Question for you: have you

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

> On Apr 8, 2016, at 10:46 AM, Антон Жилин via swift-evolution > wrote: > > 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

Re: [swift-evolution] [Pitch] Adding a Self type name shortcut for static member access

On Apr 4, 2016, at 7:13 PM, Joe Groff via swift-evolution wrote: >> On Apr 4, 2016, at 11:17 AM, Erica Sadun wrote: >>> On Apr 4, 2016, at 12:13 PM, Joe Groff wrote: >>> On Apr 4, 2016, at 11:00 AM, Erica Sadun via

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

> On Apr 8, 2016, at 8:02 AM, hitstergtd+swiftevo--- via swift-evolution > wrote: > > 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. > >

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

Inline: 2016-04-09 0:17 GMT+03:00 David Waite : > 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

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

Indeed. It's noted under "design concerns" and, IMO, raises the bar for their addition. On Sat, Apr 9, 2016 at 12:05 PM Ben Rimmington via swift-evolution < swift-evolution@swift.org> wrote: > Re: "Completing the Swift 3 range operator suite" >

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

Re: "Completing the Swift 3 range operator suite" The proposed operators (<.. and <.<) are not allowed by Swift 2.2 lexer grammar:

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

I agree with 90% of your comment. But, ranges are useful for more than just stride, and so I would say it doesn't make sense to have an intrinsic direction for Range, which pointedly has lowerBound and upperBound but not start and end. For sample, there shouldn't be (0...9).contains(1) and

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

While I’m in favour of the basic idea I think the operator selection is too complex, and I’m not sure about the need for negative strides. Really all I want are the following: (0 ... 6).striding(by: 2) // [0, 2, 4, 6] x from 0 to 6 (0 ..< 6).striding(by: 2)

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

> On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution > wrote: > > `flatten` is nowhere near as weak a term of art as `takeWhile`, but I think > it still falls towards that end of the spectrum. We shouldn't worry too much > about changing it. `map`,

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

On Sat, Apr 9, 2016 at 5:44 AM, Wallacy via swift-evolution wrote: > 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. That's not

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

On Sat, Apr 9, 2016 at 2:49 AM, Michel Fortin wrote: > 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

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

On Sat, Apr 9, 2016 at 1:00 AM, Brent Royal-Gordon wrote: >> 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, Yes, other proposals are on their way to complement this one. > and

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

On 09.04.2016 9:31, Brent Royal-Gordon wrote: This design is still very much under development—it hasn't even been reviewed, let alone added to the language. Here's the draft

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

> On Apr 7, 2016, at 1:14 PM, Anders Bertelrud via swift-evolution > wrote: > > The goal of the review process is to improve the proposal under review > through constructive criticism and, eventually, determine the direction of > Swift. When writing your review,

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

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

On 09.04.2016 6:49, Brent Royal-Gordon wrote: (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

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

The biggest missing part with this model is that we are still not able to enable macro-level optimizations in the delegating type by checking whether the delegate does provide his own implementation of an optional method or doesn’t. However, this is an important advantage of the ObjC model that