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(), etc is extremely useful. >> Swift would be a lot worse

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

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] 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 especially with regard to oth

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: > https://github.com/Anton3/swift-evolution/blob/operator-precedence/propos

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

> * What is your evaluation of the proposal? > I am in favour of this proposal. It will solve an important problem faced by swiftpm users. > * Is the problem being addressed significant enough to warrant a > change to the Swift Package Manager? > Yes, system modules often requir

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

This is my first post on this list so please bear with me. I very much like this proposal but what bothers me is this doubling of valueForKeyPath(#keyPath(xxx) in the signature of the function. chris.valueForKeyPath(#keyPath(Person.bestFriend.lastName)) // => Groff chris.valueForKeyPath(#keyPath

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

> https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md > • What is your evaluation of the proposal? I'm definitely in favor and look forward to using #keyPath. I have one note, one suggestion and one concern, but even without any of them being addressed, I

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

> On Mar 30, 2016, at 12:26 AM, Xiaodi Wu via swift-evolution > wrote: > > I didn't seem to ever need division. See attached playground (which > borrows shamelessly from existing code and Erica's proposal, and which > is written in Swift 2.2 because that's what I had handy). Appending the follo

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

> On Apr 7, 2016, at 6:12 PM, Douglas Gregor via swift-evolution > wrote: > With my proposal, we’d have some compiler-synthesized attribute (let’s call > it @__caller_default_implementation) that gets places on Objective-C optional > requirements when they get imported, e.g., > > @objc proto

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? > On Apr 7, 2016, at 5:59 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I'm confused. There is an instance owning the start and end. It's cal

Re: [swift-evolution] Limit checking syntax

I’ve found that .contains works well for all my uses. (0..<100).contains(x) > On Apr 7, 2016, at 1:17 PM, Maury Markowitz via swift-evolution > wrote: > > I originally posted this in swift-users, and it garnered some level of > positive reaction, so I thought I would try it again here. > > W

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

What is your evaluation of the proposal? Strong yes. Is the problem being addressed significant enough to warrant a change to Swift? At Delicious we wrote a huge ugly macro set to define properties in a special way so we could make key paths safely: // Declares a safe-KVC-accessible property /

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

Hi all, Optional protocol requirements in Swift have the restriction that they only work in @objc protocols, a topic that’s come up a number of times

[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 < swift-evolution at swift.org> 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 platforms

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, with reservations. The proposal itself mentions that this may be a temporary solution, and while I believe temporary solutions tend to add more complexity over the

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

If we're going to bikeshed again: how about "assign"? On Thu, Apr 7, 2016 at 7:08 PM Taras Zakharko via swift-evolution < swift-evolution@swift.org> wrote: > replaceWith* is also my favourite here (same for *InPlace). Sure, it might > be verbose, but the semantics is very clear and seems apply to

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

Conceptually, maybe? But of course the sequence is lazily evaluated, so the only state stored in an instance of StrideTo is one value for the current iteration; all the other properties in a StrideTo are just the inputs to the stride function, and no length is computed let alone stored. I get that

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

replaceWith* is also my favourite here (same for *InPlace). Sure, it might be verbose, but the semantics is very clear and seems apply to a wide range of relevant situations. In the end, there are hundreds if not more messages in this (and related) threads and i am sure that you guys spent even

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

> I'm confused. There is an instance owning the start and end. It's called > StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that it > should conform to Collection) and is distinct from Range and from the > Strideable bounds themselves. Is that different from what you're de

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

on Thu Apr 07 2016, Erica Sadun wrote: >> On Apr 7, 2016, at 2:34 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Mon Apr 04 2016, Xiaodi Wu wrote: >> >>> My read on the API guidelines is that the mutating/non-mutating distinction >>> is >>> made by verbs vs. nouns. The verb i

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

I'm confused. There is an instance owning the start and end. It's called StrideTo or StrideThrough, conforms to Sequence (with a FIXME comment that it should conform to Collection) and is distinct from Range and from the Strideable bounds themselves. Is that different from what you're describing?

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

>> Actually, it would need to be something like >> `calendar[startDate..> NSCalendarUnit is not itself a stride, it is the *unit* of the >> stride. > > Maybe: > > calendar.days[startDate.. However, it doesn't explain why > > calendar[startDate.. > “doesn't quite help.” It seems to me that

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

Hello Swift community, The review of SE-0064 "Referencing the Objective-C selector of property getters and setters" begins now and runs through April 12, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0064-property-selectors.md Reviews are a

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

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: https://github.com/Anton3/swift-evolution/blob/operator-precedence/proposals/-operator-precedence.md Sadly, I've moved into the territory opposite to what

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

> On Apr 7, 2016, at 2:34 PM, Dave Abrahams via swift-evolution > wrote: > > > on Mon Apr 04 2016, Xiaodi Wu wrote: > >> My read on the API guidelines is that the mutating/non-mutating distinction >> is >> made by verbs vs. nouns. The verb itself doesn't have to "suggest" or "feel" >> mutat

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

on Mon Apr 04 2016, Brent Royal-Gordon wrote: >> Indeed, OED points out that modern usage is "chiefly military." Probably an >> argument against its usage here. > > It seems to me that what you're sort of saying is "replaceWith", but > that's kind of a mouthful. It's at least very explicit.

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

on Mon Apr 04 2016, Xiaodi Wu wrote: > My read on the API guidelines is that the mutating/non-mutating distinction is > made by verbs vs. nouns. The verb itself doesn't have to "suggest" or "feel" > mutating, it just has to be clearly a verb. Thus, IMO, `form` is as good a > verb > as any, alth

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

on Sun Apr 03 2016, Shawn Erickson wrote: > On Sun, Apr 3, 2016 at 6:41 AM Michel Fortin via swift-evolution > wrote: > > > What is your evaluation of the proposal? > > I don't like "form" as a prefix. To me there is no difference between > `union > ` and `formUnion`: both sounds f

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

I would prefer to change them all: mapped, filtered, flatMapped, reduced, and flattened. On Friday, 8 April 2016, David Waite via swift-evolution < swift-evolution@swift.org> wrote: > In the sense that these are existing terms of art from functional > programming, they inherit the meaning of bein

[swift-evolution] Limit checking syntax

I originally posted this in swift-users, and it garnered some level of positive reaction, so I thought I would try it again here. We all constantly write code that checks a value against arbitrary ranges - subsets of an array, characters within a string, etc. This is a common example: if myVal

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

Hello Swift community, A review of "SwiftPM System Module Search Paths" for the Swift Package Manager begins now and runs through Wednesday, April 13th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0063-swiftpm-system-module-search-paths.md Rev

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

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 especially with regard to other parts of Swift or if some of it already exists. I am also aware that what I've proposed herein m

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

Hi All. nearly no one has yet reacted on my mail, echoed here again, which leaves by me the following questions pending: -does what I define and describe completely cover all the required functionality for ranges for all numerical types? -does it eliminate the need for using “Stride(...)” at

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

In the sense that these are existing terms of art from functional programming, they inherit the meaning of being non-mutating. If we did consider changing the name of one, I’d prefer if we considered all of them at once (so the various bike sheds would be painted in complementary colors) -DW

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

> On 07 Apr 2016, at 19:16, Dave Abrahams via swift-evolution > wrote: > >> It would be nice to know the rationale behind the choice of the current >> syntax. >> I agree that these seem more natural: >> >>@warn_unused_result >>public func ~=(value: I, >> pattern: >>Range) -> Bool

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

On Thu, Apr 7, 2016 at 11:27 AM, Vladimir.S wrote: > OK, thank you for the clarification Dmitri. > If these methods are going away - no possible problems :-) > Will we have some kind of .next() method for integers in new indexing model > and in Swift 3.0 in general? There would be no need to. Co

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

OK, thank you for the clarification Dmitri. If these methods are going away - no possible problems :-) Will we have some kind of .next() method for integers in new indexing model and in Swift 3.0 in general? (But actually I don't agree that there is all OK with these functions in current vers

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

on Thu Apr 07 2016, David Owens II wrote: > It would be nice to know the rationale behind the choice of the current > syntax. > I agree that these seem more natural: > > @warn_unused_result > public func ~=(value: I, > pattern: > Range) -> Bool > > @warn_unused_result > pub

Re: [swift-evolution] Missing initializers from/to FloatingPointType

The draft proposal may be easier reading: https://github.com/stephentyrone/swift-evolution/blob/master/-floating-point-protocols.md > On Apr 7, 2016, at 11:16 AM, Max Moiseev via swift-evolution > wrote: > > Hi Dan, > > New protocols are in the making for both integers and floating point

Re: [swift-evolution] Missing initializers from/to FloatingPointType

Hi Dan, New protocols are in the making for both integers and floating point numbers. You particular problem is addressed here: https://github.com/stephentyrone/swift/commits/floating-point-revision max > On Mar 30, 2016, at 6:36 AM, Dan Raviv via swift-evolution > wrote: > > While Floating

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

on Thu Apr 07 2016, Arsen Gasparyan wrote: > Hey guys, > > 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 yo

Re: [swift-evolution] divisible-by operator

Thank you for giving this a thought! milos > On 7 Apr 2016, at 15:13, Erica Sadun wrote: > >> >> On Apr 6, 2016, at 10:13 AM, Milos Rankovic via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Checking for divisibility is very common: >> >> 21 % 3 == 0 // true >> >>

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

on Thu Apr 07 2016, Brent Royal-Gordon wrote: >>> calendar.using(.Day).stride(from: startDate, to: endDate, by: 1) >> >>> The `start` and `end` parameters could be grouped together into a >>> single parameter to match `stride(over:by:)`, but you can't put the >>> calendar or the unit into the s

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

I'd prefer to offer both ~= and =~, allowing the consumer to choose which side the pattern sits on. -- E > On Apr 7, 2016, at 11:09 AM, David Owens II via swift-evolution > wrote: > > It would be nice to know the rationale behind the choice of the current > syntax. I agree that these seem m

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

On Thu, Apr 7, 2016 at 12:20 AM, Vladimir.S via swift-evolution wrote: > But. .successor() .predecessor() methods for Int values do not follow these > rules for overflow situations. I.e. : > let i : Int8 = Int8.max > let k : Int8 = i.successor() > - is OK for current Swift compiler. We have i==127

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

This is exactly why I think successor()/predecessor() must raise runtime error on integer overflow - because we(I believe) expect this behavior from these funcs. For example, someone, who don't know about current behavior of these methods, can use them to increment/decrement index for some coll

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

It would be nice to know the rationale behind the choice of the current syntax. I agree that these seem more natural: @warn_unused_result public func ~=(value: I, pattern: Range) -> Bool @warn_unused_result public func ~=(value: I.Bound, pattern: I) -> Bool I would not change from `~=` to `=~`

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

Hello Swift community, The review of SE-0062 “Referencing Objective-C key-paths" begins now and runs through April 12, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0062-objc-keypaths.md Reviews are an important part of the Swift evolution p

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

I agree. The related types (currently FlattenCollection, FlattenSequence) should get renamed as well. Cheers, Guillaume Lessard ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution

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 goi

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

A different direction would be to add a non-autoclosure variant to ?? that explicitly takes a closure. public func ??(optional: T?, defaultValue: () throws -> T) rethrows -> T { switch optional { case .Some(let wrapped): return wrapped case .None: return try defaultValue() } } Then, the

[swift-evolution] Proposal: Add scan, takeWhile, dropWhile, and iterate to the stdlib

> > On Jan 10, 2016, at 10:20 PM, Kevin Ballard via > > swift-evolutionwrote: > > > > When the proposal is "we have a bunch of functions that match functions > > used in other languages, lets add a few more from the same category of > > functions that we missed", does there really need to be mu

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

Because I am a mailing list noob, my email wasn't CC'd to all. So here we go again: Big +1 from me. I expected not to like this syntax but I believe it makes it far clearer. It always felt backwards to me to have to come up with all the constraints before the function signature. Maybe this is

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

> On Apr 6, 2016, at 11:09 PM, David Hart wrote: > > 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 > conf

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

> On 7 Apr 2016, at 14:17, Brent Royal-Gordon wrote: > >> As I understand it, the proposal is that `Self` can be used as an alias to >> `self.dynamicType`, which is an object in the sense of entity in Swift but >> not an instance of a class or struct. > > You don't understand it correctly.

Re: [swift-evolution] divisible-by operator

> On Apr 6, 2016, at 10:13 AM, Milos Rankovic via swift-evolution > wrote: > > Checking for divisibility is very common: > > 21 % 3 == 0 // true > > In fact, this is such a common use of the `%` operator that the `== 0` side > of the expression seems distracting in this use case. For qui

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

> On Apr 7, 2016, at 6:17 AM, Brent Royal-Gordon via swift-evolution > wrote: > Having said all this, now that we have `#Self`, I'm wondering if we still > want `Self` in value types. The two are *exactly* equivalent in value types > as far as I can tell, and `Self` in classes implies dynamic

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

Of course we can implement a library with `throws` by changing those properties to methods. However we can think about similar cases. ``` do { let foo: Foo = try foo( a: Int(aString) ??? Error(), b: Int(bString) ??? Error(), c: Int(cString) ??? Error() ) } catch _ {

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

Hey guys, 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? Implementation: https://github.com/apple/swift/

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

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

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] [Pitch] Adding a Self type name shortcut for static member access

> As I understand it, the proposal is that `Self` can be used as an alias to > `self.dynamicType`, which is an object in the sense of entity in Swift but > not an instance of a class or struct. You don't understand it correctly. Currently, `Self` in a class definition means "whatever subclass

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

>> calendar.using(.Day).stride(from: startDate, to: endDate, by: 1) > >> The `start` and `end` parameters could be grouped together into a >> single parameter to match `stride(over:by:)`, but you can't put the >> calendar or the unit into the stride—without them, there is no >> coherent way t

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

> I'd like to see some real-world examples of this before we did anything with > it. The following is my real-world example. ``` // Decodes a JSON with SwiftyJSON do { let person: Person = try Person( firstName: json["firstName"].string ??? Error(), lastName: json["lastName"].string ??

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

These are fantastic proposals! With these in place, there would be precious little to envy Haskell. For example, regarding “counter-proposal against making generic parameters public”, the current behaviour of Swift is essentially a bug, as reported by Noah Blake (https://bugs.swift.org/browse/

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

Hi all, Swift has a pattern match operator, ~=, which is unknown to many (like me until a few weeks ago), that performs a match between a value and a certain pattern, e.g. checking if an integer value is contained in a range of integers. This operator may be little known, but it plays a key role

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

I quite like this variation, so I’m a +1 for that. However, I think this would be greatly helped if we could define protocol generics more like type generics like so: protocol Foo { … } func anyStringFoo(lhs:Foo) { … } But yeah, for the more complicated cases, it makes a lot of

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

> On 7 Apr 2016, at 08:20, Vladimir.S via swift-evolution > wrote: > > (TLDR: Suggest to change successor() method for Int values to follow default > Swift rules for integer overflow. Probably some kind of successorWithOverflow > could be introduced to use when needed) I’m a +1 for this; in

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

> On 6 Apr 2016, at 18:16, Dave Abrahams via swift-evolution > wrote: > > > on Wed Apr 06 2016, Jeremy Pereira wrote: > >> 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 capita

Re: [swift-evolution] divisible-by operator

Personally I’d prefer to use a method like: 21.isDivisibleBy(3) As it’s clearer IMO. My problem with the operator is that it doesn’t make logical sense to have the value you’re dividing by on the right hand side when there are equals signs, it seems more like this should be the value yo

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

Jordan, Your comments brought up a few more closely related ideas that have been bubbling under. To everyone, Sorry for going beyond topic here. The discussion of the further proposals below should be taken into their own threads if there's interest. I'm just trying to motivate what else movi

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

Hi All! (Please let me know if that was already discussed. Searched, found nothing related to such proposal.) (TLDR: Suggest to change successor() method for Int values to follow default Swift rules for integer overflow. Probably some kind of successorWithOverflow could be introduced to use w