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

There is no spec, but the man page has info on what you asked http://linux.die.net/man/1/pkg-config > Hi Max, > > The proposal refers to "the pkg-config specification", can you add a link to > that? In particular, I am curious how SwiftPM will know where to look for > those files. > > -

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

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 the syntax can be for these kinds of operations. For example, the Swift book

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):

Re: [swift-evolution] deployment targets and frameworks

On Wed, Apr 6, 2016 at 9:58 AM, Douglas Gregor via swift-evolution < swift-evolution@swift.org> wrote: > > On Apr 5, 2016, at 4:04 PM, Drew Crawford wrote: > > > On Apr 5, 2016, at 12:06 PM, Douglas Gregor wrote: > > I would not want this to be

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

> On Apr 6, 2016, at 11:26 AM, Erica Sadun wrote: > >> >> 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

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

> 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

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

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 :

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

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

> On Apr 6, 2016, at 11:10 AM, Dave Abrahams wrote: > Again, I wasn't trying to suggest any of the solutions listed there. > The point I was making was that we don't have enough information to > design more than > >(0..<200).striding(by: -2) I like this a lot but I

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

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 straightforward to > express with the current free function--I

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

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

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

> On Apr 6, 2016, at 10:10 AM, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Brent Royal-Gordon wrote: > >>> For example, there are all kinds of other ways to slice this: >>> >>> stride(over: 0..<200, by: -2) >> >> This seems like a

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 :

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 >>

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,

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

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

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 straightforward to express with the current free function--I hadn't considered that. Meanwhile, I was trying to talk

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

on Wed Apr 06 2016, Milos Rankovic wrote: > On 6 Apr 2016, at 18:57, Xiaodi Wu via swift-evolution > wrote: > > Meanwhile, I was trying to talk about something like `stride(from: 200, > to: > 0, by: -2)`, which is easily expressed today but isn't

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

on Wed Apr 06 2016, Stephen Canon 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 via swift-evolution > wrote: > > One question

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] [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

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,

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

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 where on disk the .pc files live. How are we going to know that? For

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

> On 6 Apr 2016, at 18:57, Xiaodi Wu via swift-evolution > wrote: > > Meanwhile, I was trying to talk about something like `stride(from: 200, to: > 0, by: -2)`, which is easily expressed today but isn't straightforward at all > to preserve with only ranges.

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

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

>>> 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") else { throw >>> InitializerError.invalidString } >> >> That is a pretty

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:

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 ==

[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:

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

> 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 where on disk the .pc > files live. How are we going to know

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

> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution > wrote: > > One question that I *do* think we should answer, is whether the elements > of > >(0..<199).striding(by: -2) > > are even or odd. Odd. I don’t believe that many real use cases care,

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

> 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 (0..<198).striding(by: -2): 1..<198

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 ==

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

on Wed Apr 06 2016, Brent Royal-Gordon wrote: >> For example, there are all kinds of other ways to slice this: >> >>stride(over: 0..<200, by: -2) > > This seems like a particularly good solution. The way I understand it > at least, it would allow ranges to always be ordered, with the only

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

> On Apr 5, 2016, at 5:57 PM, Kevin Lundberg via swift-evolution > wrote: > > Generally I'm +1 on this, but I do have a concern. It's not made explicit in > the proposal, but I presume that this is meant to only be available on > Darwin, and not Linux or other

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

on Wed Apr 06 2016, Russ Bishop wrote: > On Apr 5, 2016, at 1:39 PM, Dave Abrahams via swift-evolution > wrote: > > A few thoughts: > > 1. It would have made it easier to evaluate if the proposal had not > talked about

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

> On Apr 6, 2016, at 11:20 AM, Stephen Canon via swift-evolution > wrote: > >> On Apr 6, 2016, at 11:16 AM, Dave Abrahams via swift-evolution >> > wrote: >> >> One question that I *do* think we should

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] 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

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

> 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: > >

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

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

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

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

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 >

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

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 >>>

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

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

[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

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: >>>

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

> 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

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

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 >>

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

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,

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

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,

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. > >

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,

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

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] 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

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

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

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 >

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

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

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

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,

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

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,

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. >>

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

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

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

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

> Alternatively, why is it ‘dynamicType’ and not just ‘type’? I suspect this has something to do with the 27 methods in various OS X frameworks named `type`. (To be fair, 17 of those are in WebKit's DOM classes.) What I'm less sure about is why it's not a free function instead. Other than the

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

> > I don't think there's much of a point solving this just for associated > types. The same issue exists for all protocol requirements. True enough. The one difference worth noting, however, is that there's no way to address the ambiguity of identical protocol requirements without adding

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

Great solution for C interop! Eventually, annotations for C language and API notes could be replaced with such automatically-generated-manually-correctable bridge files. We could support a wide range of conversions for @shadowing_c, such as convertion of IUO to optional or unwrapped type. There

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 >> > wrote: >> >> I think this is a good idea, though I would put

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

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

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

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

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] [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

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] 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

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 >

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

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

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:

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 <

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 think people are reading a ..< b as the mathematical notation [a, b) which means {}, null, or empty, not error, if b < a and {a} if b = a. If Range was changed to be an Array like collection indexed from 0 to count and stride was how the indexed counted and was an Int > 0 then the following

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

I think I would be -1 on this. The proposal is that there be two names, Self and self that refer to different objects but are differentiated only by the capitalisation of the first letter and these could be mixed in the same context. I think this would make code that uses both harder to read.

  1   2   >