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

Dijkstra is talking about intervals of natural numbers, i.e. indices. Range is much more general than that, including floating point ranges, so Dijkstra's arguments do not apply here. -Thorsten Am 06.04.2016 um 23:41 schrieb Brent Royal-Gordon via swift-evolution : >> From a purely numericall

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

> Am 06.04.2016 um 23:26 schrieb Stephen Canon via swift-evolution > : > > >> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >>> on Wed Apr 06 2016, Erica Sadun wrote: >>> >>> On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution >>>wrote: >>>

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

> Am 06.04.2016 um 23:03 schrieb Dave Abrahams via swift-evolution > : > > >> on Wed Apr 06 2016, Erica Sadun wrote: >> >>On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution >> wrote: >> >>Guidance: >> >>When using odd integer literals to produce an even numbe

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

I agree with Sean, I ready use guard and don't see much use in a StdLib or operator alternative. Sent from my iPad > On 06 Apr 2016, at 17:00, Sean Heber via swift-evolution > wrote: > > Interesting, but I’m unsure if all of it is significantly better than just > using the guard that is effe

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

There's something I find very confusing with this proposal, and it's how Self is already used in protocol definitions to represent the STATIC type of the type that conforms to the protocol. I think people will be potentially very confused by how Self represents different types in different conte

Re: [swift-evolution] divisible-by operator

This is the kind of thing that I'd let live in a library and consider importing into the standard if a lot of people use it. Félix > Le 6 avr. 2016 à 09:13:41, Milos Rankovic via swift-evolution > a écrit : > > Checking for divisibility is very common: > > 21 % 3 == 0 // true > > In fac

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

> Am 06.04.2016 um 22:17 schrieb Xiaodi Wu via swift-evolution > : > >> On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams wrote: >> >>> on Wed Apr 06 2016, Erica Sadun wrote: >>> >>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >>> wrote: >>>(0..<199).striding(by: -

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

> Am 06.04.2016 um 20:26 schrieb Erica Sadun via swift-evolution > : > >>> On Apr 6, 2016, at 12:23 PM, Stephen Canon via swift-evolution >>> wrote: >>> >>> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution wrote: On Apr 6, 2016, at 11:16 AM, Dave Abrahams

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

> On Apr 6, 2016, at 9:21 AM, Brent Royal-Gordon via swift-evolution > wrote: >>> Interesting, but I’m unsure if all of it is significantly better than just >>> using the guard that is effectively inside of the operator/func that is >>> being proposed: >>> >>> guard let value = Int("NotANumber

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

> I know you're not proposing that feature right now, but want to understand > how you expect it to work. It looks to me like this starts to enter design > by contract territory. Would the predicate behave as if it was part of a > precondition? I suppose I imagine it as equivalent to a precon

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

Another +1 to `where` at the end. On Wed, Apr 6, 2016 at 10:33 PM, Matt Whiteside via swift-evolution < swift-evolution@swift.org> wrote: > +1 to moving the `where` clause after the function signature. > > -Matt > > > On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution < > swift-evolution@swi

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

+1 to moving the `where` clause after the function signature. -Matt > On Apr 6, 2016, at 12:36, Joe Groff via swift-evolution > wrote: > > >> 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

Re: [swift-evolution] [Review] SE-0058: Allow Swift types to provide custom Objective-C representations

On 4/6/2016 1:22 PM, Russ Bishop wrote: > The original intent was to be available on platforms that have an > Objective-C runtime (Darwin only at the moment, I guess in theory > Windows if someone were determined enough). > > > You bring up a good point; there is nothing in the protocol that > ab

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

> On Apr 6, 2016, at 17:00, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu wrote: >>> Prohibiting StrideTo with floating-point ranges altogether would be >>> distressing. IMO, it's plenty distressing that

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

I agree with this and I like the operator approach. Besides the proposed infix `???`, I also want the postfix one which throws a `NilError` (something like `struct NilError: ErrorType {}`). It is useful to handle multiple `nil`s at once when we are not interested in the kind of the error. ``` //

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

I like the idea that Array gains `strinding(by:)` but would also like Range to be like an array, same interface, and hence also gain `strinding(by:)`, hence: calendar[(startDate ..< endDate).striding(by: .Day)] -- Howard. On 7 April 2016 at 10:53, Dave Abrahams via swift-evolution < swift-evo

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

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> I (am familiar with and) agree with Dijkstra's logic, but not with your >> conclusion about it. The fact that one representation is more natural >> for most common computing tasks doesn't mean it's not worth supporting >> the other representation

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

I like the idea, I find the beginning of a declaration too cluttered and it obscures the main purpose. Like Brent I am wary of the design by contract (DBC) bit, `lhs <= rhs`. DBC is probably for a separate discussion, but moving the where clause would probably help. -- Howard. On 7 April 2016 a

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

Sent from my iPad On Apr 6, 2016, at 7:13 PM, Brent Royal-Gordon via swift-evolution wrote: >> I would actually move them as far as after everything else, and right before >> the definition body. For the above function that would mean: >> >> func anyCommonElements(lhs: T, _ rhs: U) -> Bool

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

I'm hoping this extends to type values. struct StructWithClosure { let closure : (lhs: Element, rhs:Element) -> Range where Element : Incrementable, Comparable } or for that matter, protocol values: struct StructWithIntCollectionType { let collection : C where C : CollectionType, C.Elemen

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

> I would actually move them as far as after everything else, and right before > the definition body. For the above function that would mean: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool > where T : SequenceType, > U : SequenceType, > T.Generator.Element: Equatable

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

It's probably appropriate. Given that, in this example, Bar implicitly unifies its generic constraint T with Foo's associatedtype T (or, typealiases T with T), you need to be at least a little careful how you name your generic constraints. protocol Foo { associatedtype T } struct Bar : Foo {

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

> On Apr 6, 2016, at 16:52, Erica Sadun via swift-evolution > wrote: > >> >> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution >>> mailto:swift-evolution@swift.org>> w

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

> I (am familiar with and) agree with Dijkstra's logic, but not with your > conclusion about it. The fact that one representation is more natural > for most common computing tasks doesn't mean it's not worth supporting > the other representations. I'm not saying that Dijkstra proves that we don't

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

> On Apr 6, 2016, at 5:45 PM, David Waite via swift-evolution > wrote: > > >> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> I think this is a good idea, though I would put the `where` clause after the >> function signature: >>

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

> On Apr 6, 2016, at 1:36 PM, Joe Groff via swift-evolution > wrote: > > I think this is a good idea, though I would put the `where` clause after the > function signature: > > func foo(x: T, y: U) -> Result >where T.Foo == U.Bar /*, etc. */ > { > } A bit of a meta-argument: It is very c

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

on Wed Apr 06 2016, Howard Lovatt wrote: > Dijkstra specifically said that in Mesa it was a bad idea to include anything > other than `..<` the relevent quote is: > > "Extensive experience with Mesa has shown that the use of the other three > conventions has been a constant source of clumsiness

Re: [swift-evolution] [Proposal] Threadsafe lazy vars

> On Apr 6, 2016, at 2:07 PM, Michael Peternell via swift-evolution > wrote: > > Hi all, > > lazy vars are not threadsafe in Swift 2. I saw code that uses lazy > initialization in an unsafe way that introduces race conditions so often that > I would be rich by now if get a penny each time. M

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

Personally I would like Optional to gain `ifNil` (`??` would call `ifNil`) and `ifNilThrow`, both of which have an auto closure argument returning a value and throwing respectively. This would save adding an extra operator and allow chaining to read better than `??` in some circumstances, like when

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

> Le 6 avr. 2016 à 16:03, Joe Groff via swift-evolution > a écrit : > > >> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola wrote: >> >> Joe, >> >> Just from your experience on this topic, is there any reason not to also >> move the primary constraints into the trailing `where` clause? >> >> So

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

Dijkstra specifically said that in Mesa it was a bad idea to include anything other than `..<` the relevent quote is: "Extensive experience with Mesa has shown that the use of the other three conventions has been a constant source of clumsiness and mistakes, and on account of that experience Mesa

Re: [swift-evolution] SE-0025: Scoped Access Level, next steps

I am opposed to any change to the current access level system. What we have now is simple, approachable and handles all real cases for limiting or granting access. Any additions will just serve to complicate the current system without sufficient offsetting benefit. Further additions will jus

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

> Agreed. Let me ask the question differently: what value does the > leading `.` provide to the user of the language? I find the leading-dot syntax to be very useful; it's a pretty clear shorthand that I'm not referencing something at global scope. Here's a common example from our codebase:

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

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> From a purely numerically aesthetic point of view, I'd much prefer ranges to >> be >> openable and closable at both ends. >> >> My primary use-case has been teaching math using playgrounds but I'm sure >> there are lots of other real-world si

Re: [swift-evolution] Generic Alaises

Hi Ross, That was a hell of an example! However, even with the types as they are now, the code needn’t look so dreadful. With following protocols in place: protocol Indexed { associatedtype Index : Hashable var index: Index { get } } protocol NodeType : Indexed { } protocol Edge

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

Hi Milos Yes, (v1…v2).by(v3) it can determine the going of either in + or - direction, but only at run time! because the contents of v1, v2, v3 are of course unknown at compile time. Ergo: it cannot expected be an absolute value. however, I suggested (coded) that here on 4.3.2016… Works in

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

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution > wrote: > > on Wed Apr 06 2016, Xiaodi Wu wrote: > > On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution > wrote: > > You if you need to re

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

> From a purely numerically aesthetic point of view, I'd much prefer ranges to > be > openable and closable at both ends. > > My primary use-case has been teaching math using playgrounds but I'm sure > there are lots of other real-world situations more specific to common > numerical > method

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

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 reversed, you'd do just that: > > (0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0] > > Als

Re: [swift-evolution] deployment targets and frameworks

> On Apr 6, 2016, at 1:35 PM, Douglas Gregor > wrote: > > Fortunately, Swift tells you when you get it wrong. It doesn't, though. That's the thing. Consider CloudKit, first available in iOS 8. Does that framework's implementation rely on new, novel APIs only availa

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

> On Apr 6, 2016, at 3:25 PM, Dave Abrahams wrote: > > These all look reasonable to me. > >>Lastly, if you want the positive stride reversed, you'd do just that: >> >>(0 ... 9).striding(by: 2).reverse() == [8, 6, 4, 2, 0] > > Also reasonable. > > -- > Dave Unless there's a compelli

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

> On Apr 6, 2016, at 2:25 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Wed Apr 06 2016, Xiaodi Wu wrote: >> >>On Wed, Apr 6, 2016 at 3:28

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

Hi Ted, > that would imply the ‘by”value should/must always be an absolute value? In a way: Instead of `Strideable.Stride` I would suggest `Strideable.Distance`. At any rate, leaving the sign to be direction indicator makes it forever necessary for everyone to make this counterintuitive metal

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

On Wed, Apr 6, 2016 at 4:05 PM, Dave Abrahams wrote: > > on Wed Apr 06 2016, Xiaodi Wu wrote: > >> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution >> wrote: >>> You if you need to represent `<..` intervals in scientific computing, >>> that's a pretty compelling argument for sup

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

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution > wrote: > > Guidance: > > When using odd integer literals to produce an even number sequence, > prefer the `...` operator to the `..<` operator and change your end

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

> On Apr 6, 2016, at 3:05 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Xiaodi Wu > wrote: > >> On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution >> wrote: >>> You if you need to represent `<..` intervals in scientif

[swift-evolution] [Proposal] Threadsafe lazy vars

Hi all, lazy vars are not threadsafe in Swift 2. I saw code that uses lazy initialization in an unsafe way that introduces race conditions so often that I would be rich by now if get a penny each time. Many people use patterns like { if(_var == nil) { _var = [self _calculateVar]; } return _var;

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

on Wed Apr 06 2016, Xiaodi Wu wrote: > On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution > wrote: >> You if you need to represent `<..` intervals in scientific computing, >> that's a pretty compelling argument for supporting them. >> >>> I'd like to be able to represent any of t

Re: [swift-evolution] Notes from Swift core team 2016-04-05 design discussion

I don’t think the notes were conveying a decided-upon solution, so much as a fervent discussion which did not yet yield a conclusion. If you have an idea of how to address this, could you put together a draft? > On Apr 6, 2016, at 3:39 AM, Антон Жилин via swift-evolution > wrote: > > Great so

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

On Wed, Apr 6, 2016 at 3:28 PM, Dave Abrahams via swift-evolution wrote: > You if you need to represent `<..` intervals in scientific computing, > that's a pretty compelling argument for supporting them. > >> I'd like to be able to represent any of those as >> Intervals-which-are-now-Ranges. It ma

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

on Wed Apr 06 2016, Erica Sadun wrote: >> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu wrote: >> Prohibiting StrideTo with floating-point ranges altogether would be >> distressing. IMO, it's plenty distressing that backwards >> floating-point StrideTo as it currently exists might go away. > > I wouldn

Re: [swift-evolution] Generic Alaises

Ross put it better than I ever could :) yes this is what I meant  Sent from Supmenow.com On Wed, Apr 6, 2016 at 1:45 PM -0700, "Ross O'Brien" wrote: It's not the same topic. Let's take an example: suppose we have a data structure for a graph of nodes and edges, where the nodes and

Re: [swift-evolution] Generic Alaises

It's not the same topic. Let's take an example: suppose we have a data structure for a graph of nodes and edges, where the nodes and edges are indexed and both have values. So we have a Graph. Now suppose we want a shortest path from one node to another, and we have a data structure to represent th

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

G Typos… Sorry, here it is again: vital correctionslook at<< < Hi Erica, Dave Based on what I’ve (not all) read under this topic: I’d suggest a more complete approach: Ranges should support: (as yet not implemented) - All numerical data types (Double, Float, Int, Money

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

On Wed, Apr 6, 2016 at 1:29 PM Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote: > > On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > I don't think you can fix counterintuitive behavior with guidance. > > (1..<199).striding(by

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

> On Apr 6, 2016, at 1:21 PM, Pyry Jahkola wrote: > >> Joe Groff wrote: >> >> It's a judgment call. It's my feeling that in many cases, a generic >> parameter is constrained by at least one important protocol or base class >> that's worth calling out up front, so it's reasonable to allow thin

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

> On Apr 6, 2016, at 2:35 PM, Erica Sadun via swift-evolution > wrote: > > Yes, but you can with warnings and fixits. > > * The compiler should issue a warning for any use of > > (n.. > with a fixit of "replace (n.. whether n or m is known at compile time > > * If v cannot be known at c

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

> On Apr 6, 2016, at 2:28 PM, Dave Abrahams via swift-evolution > wrote: > You if you need to represent `<..` intervals in scientific computing, > that's a pretty compelling argument for supporting them. >From a purely numerically aesthetic point of view, I'd much prefer ranges to >be openabl

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

> On Apr 6, 2016, at 2:17 PM, Dave Abrahams via swift-evolution > wrote: >> Guidance: >> >> When using odd integer literals to produce an even number sequence, >> prefer the `...` operator to the `..<` operator and change your ending >> literal to an even number. > > I don't think you can fix

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

Hello Milos, Good question was thinking about this too. that would imply the ‘by”value should/must always be an absolute value? however (if it is a var) it cannot be guaranteed to be + or - that’s why I thought to leave it as is. ? TedvG > On 06.04.2016, at 22:18, Milos Rankovic wrote: > > >>

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

on Wed Apr 06 2016, Xiaodi Wu wrote: > On Wed, Apr 6, 2016 at 1:16 PM, Dave Abrahams wrote: >> >> on Wed Apr 06 2016, Xiaodi Wu wrote: >> >>> I think a lightbulb just went on for me: >>> > >>> You're talking about expressing something in the vein of >>> `(0..<200).striding(by: >>> -2)`, which

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

> On Apr 6, 2016, at 2:17 PM, Xiaodi Wu wrote: > Prohibiting StrideTo with floating-point ranges altogether would be > distressing. IMO, it's plenty distressing that backwards > floating-point StrideTo as it currently exists might go away. I wouldn't suggest doing so. I'm just saying that for a

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

> On 06 Apr 2016, at 23:17, Dave Abrahams via swift-evolution > wrote: > > I don't think you can fix counterintuitive behavior with guidance. > > (1..<199).striding(by: -2) is the first way I'd reach for to express > 197, 195, ..., 3, 1 I think a sensible specification would be that with a

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

On Apr 6, 2016, at 2:03 PM, Joe Groff via swift-evolution wrote: > >> >> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola wrote: >> >> Joe, >> >> Just from your experience on this topic, is there any reason not to also >> move the primary constraints into the trailing `where` clause? > It's a judg

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

I think the where clause should be moved to the end as you outlined an any constraints beyond simple statements of conformance to a protocol or superclass should only be allowed in the where clause. If someone desires to state simple conformance/superclass for a generic parameter they should be all

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

> Joe Groff wrote: > > It's a judgment call. It's my feeling that in many cases, a generic parameter > is constrained by at least one important protocol or base class that's worth > calling out up front, so it's reasonable to allow things like 'func foo Collection>(x: C) -> C.Element' without ba

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

Apologies, I inverted the operator there! This is, of course what I meant: > On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution > wrote: > > v1 > v2: is allowed and correctly evaluated. e.g. > (8.0…-3.14159).by(-0.0001) If the range does not assume `start <= end`, is it sti

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

on Wed Apr 06 2016, Erica Sadun wrote: >> On Apr 6, 2016, at 12:43 PM, Dave Abrahams wrote: >> >> >> on Wed Apr 06 2016, Erica Sadun wrote: >> > >>>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >>> wrote: >>>(0..<199).striding(by: -2) >>> >>>are even or odd

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

> On 6 Apr 2016, at 21:08, Ted F.A. van Gaalen via swift-evolution > wrote: > > v1 > v2: is allowed and correctly evaluated. e.g. > (8.0…-3.14159).by(-0.0001) If the range does not assume `start >= end`, is it still necessary to also indicate the traversal direction with the sign of the

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

On Wed, Apr 6, 2016 at 1:43 PM, Dave Abrahams wrote: > > on Wed Apr 06 2016, Erica Sadun wrote: > >> On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >> wrote: >> (0..<199).striding(by: -2) >> >> are even or odd. >> >> (0..<199).striding(by: -2): 0..<199 == 0...198

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

> On Apr 6, 2016, at 12:52 PM, Pyry Jahkola wrote: > > Joe, > > Just from your experience on this topic, is there any reason not to also move > the primary constraints into the trailing `where` clause? > > So instead of what you wrote, we'd have it this way: > > func foo(x: T, y: U) -> R

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

On Wed, Apr 6, 2016 at 1:16 PM, Dave Abrahams wrote: > > on Wed Apr 06 2016, Xiaodi Wu wrote: > >> I think a lightbulb just went on for me: >> >> You're talking about expressing something in the vein of >> `(0..<200).striding(by: >> -2)`, which has I'm sure many use cases, and which isn't straig

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

Hi Erica, Dave Based on what I’ve (not all) read under this topic: I’d suggest a more complete approach: Ranges should support: (as yet not implemented) - All numerical data types (Double, Float, Int, Money***, Decimal*** ) - An arbitrary increment or decrement value. - Working in the compl

Re: [swift-evolution] Generic Alaises

Chris Lattner has a proposal under review on this topic. milos > On 6 Apr 2016, at 20:41, James Campbell via swift-evolution > wrote: > > This was inspired from the topic about moving where clauses ou

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

> For example, this Standard Library function: > > public func + < > C : RangeReplaceableCollectionType, > S : SequenceType > where S.Generator.Element == C.Generator.Element > > (lhs: C, rhs: S) -> C > > would become: > > public func + (lhs: C, rhs: S) -> C w

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

Joe, Just from your experience on this topic, is there any reason not to also move the primary constraints into the trailing `where` clause? So instead of what you wrote, we'd have it this way: func foo(x: T, y: U) -> Result where T: Foo, U: Bar, T.Foo == U.Bar /*, etc. */ {

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

I don’t see much value in moving them out of the angle brackets but preserving the position; consider: // status-quo: func anyCommonElements (lhs: T, _ rhs: U) -> Bool // as-per proposal: func anyCommonElements where T.Generator.Element: Equatable, T.Generator.Elem

[swift-evolution] Generic Alaises

This was inspired from the topic about moving where clauses out of parameter lists. Certain generics get very long winded, I was wondering if we could create some sort of alias for generics. func anyCommonElements (lhs: T, _ rhs: U) -> Bool could be shared across functions like so: genericalia

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 operator, you know what a pa

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

Even better. +1. ~Robert Widmann 2016/04/06 14:35、Pyry Jahkola via swift-evolution のメッセージ: >> On 06 Apr 2016, at 21:30, 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

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

> On 6 Apr 2016, at 19:48, Sean Heber wrote: > > This almost seems like it could work so that it didn't even need the > bracketed parts to be able to figure out the types: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool where >T : SequenceType, >U : SequenceType, >T.Generator.

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

I would think it’d just be unconstrained generic parameters - same as this is now: func f(lhs: A, _ rhs: B) {} However I can see how it’d certainly be potentially too confusing. It might be worthwhile to retain the brackets, but require type restrictions to be moved to the trailing “where” so

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

+1. I like the idea of seeing the function signature first, then the constraints. > On Apr 6, 2016, at 3:47 PM, Milos Rankovic via swift-evolution > wrote: > > >> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> func anyCommonElem

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

With `where` at the end, the Standard Library function: public func != < A : Equatable, B : Equatable, C : Equatable, D : Equatable, E : Equatable, F : Equatable > (lhs: (A, B, C, D

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

> On Apr 6, 2016, at 12:43 PM, Dave Abrahams wrote: > > > on Wed Apr 06 2016, Erica Sadun wrote: > >>On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution >> wrote: >>(0..<199).striding(by: -2) >> >>are even or odd. >> >> (0..<199).striding(by: -2): 0..<199 == 0...1

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

A big +1 to this notation. > On 06 Apr 2016, at 20:47, Milos Rankovic via swift-evolution > wrote: > > >> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> func anyCommonElements(lhs: T, _ rhs: U) -> Bool >> where T : SequenceT

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

> This almost seems like it could work so that it didn't even need the > bracketed parts to be able to figure out the types: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool where >T : SequenceType, >U : SequenceType, >T.Generator.Element: Equatable, >T.Generator.Element == U.

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

> On Apr 6, 2016, at 12:30 PM, 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 operator, you know what a pa

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

> On Apr 6, 2016, at 11:48 AM, Sean Heber via swift-evolution > wrote: > > This almost seems like it could work so that it didn't even need the > bracketed parts to be able to figure out the types: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool where >T : SequenceType, >U : Sequ

Re: [swift-evolution] Draft Proposal SwiftPM System Module Search Paths

> On Apr 6, 2016, at 11:11 AM, Max Howell wrote: > >> I don't see that information in the man page (also, I am not familiar enough >> with pkg-config to know how results described in that man page translate to >> other systems). >> >> Specifically, that man page does not seem to document wher

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

This almost seems like it could work so that it didn't even need the bracketed parts to be able to figure out the types: func anyCommonElements(lhs: T, _ rhs: U) -> Bool where T : SequenceType, U : SequenceType, T.Generator.Element: Equatable, T.Generator.Element == U.Generator.El

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

> On 6 Apr 2016, at 19:35, Pyry Jahkola via swift-evolution > wrote: > > func anyCommonElements(lhs: T, _ rhs: U) -> Bool > where T : SequenceType, > U : SequenceType, > T.Generator.Element: Equatable, > T.Generator.Element == U.Generator.Element > { > ...

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

on Wed Apr 06 2016, Erica Sadun wrote: > On Apr 6, 2016, at 12:16 PM, Dave Abrahams via swift-evolution > wrote: > (0..<199).striding(by: -2) > > are even or odd. > > (0..<199).striding(by: -2): 0..<199 == 0...198 Even > (1..<199).striding(by: -2): 1..<199 == 1...198 Even I und

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

> The same would work for generic types too: > > public struct Dictionary > where Key : Hashable > { >... > } And I'm not sure if people feel the same as me, but I haven't been happy with the current way generic arguments (such as Key and Value above) magically appear in type extension

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

*grabs paintbrush* Something that has always bothered me about the generic syntax for functions is how far the function’s name is from its parameters. There are probably reasons why the following might not work, but it could address my desire to keep the name of the thing close to the names of

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

On Wed, Apr 6, 2016 at 11:36 AM Pyry Jahkola via swift-evolution < swift-evolution@swift.org> wrote: > On 06 Apr 2016, at 21:30, Developer via swift-evolution < > swift-evolution@swift.org> wrote: > > > If you've ever gotten to the point where you have a sufficiently generic > interface to a thing

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

> On Apr 6, 2016, at 12:30 PM, Dave Abrahams via swift-evolution > wrote: > on Wed Apr 06 2016, Stephen Canon wrote: >> For the (0..<199) case, Erica’s assessment > > which is...? https://gist.github.com/erica/786ab9703f699db1301be65510e7da03

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

> On 6 Apr 2016, at 19:16, Dave Abrahams via swift-evolution > wrote: > > We prefer methods to free functions. However, `(from:to:by)` need not be a free function, it could be a sequence initialiser: Walk(from: 200, to: 0, by: 2) or: Steps(from: 200, to: 0, by: 2) or something alo

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

> On 06 Apr 2016, at 21:30, 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 operator, you know what a pain t

Re: [swift-evolution] deployment targets and frameworks

> On Apr 6, 2016, at 11:04 AM, Jonathan Tang wrote: > > > > On Wed, Apr 6, 2016 at 9:58 AM, Douglas Gregor via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> On Apr 5, 2016, at 4:04 PM, Drew Crawford > > wrote: >> >> >>> On Apr 5, 2016, at

  1   2   >