Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

[[iOS messageWithData:ideas] broadcast] > On 26 Apr 2016, at 07:28, David Owens II via swift-evolution > wrote: > > What is your evaluation of the proposal? > I reluctantly agree with the proposal with the following caveat: I do not > agree with the rationale to support being able to choose t

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

What is your evaluation of the proposal? I reluctantly agree with the proposal with the following caveat: I do not agree with the rationale to support being able to choose to omit the () for the parameter list of the closure declaration. I see no cohesive argument that says that the parens shoul

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> Le 26 avr. 2016 à 08:07, Chris Lattner a écrit : > > On Apr 25, 2016, at 10:48 PM, Gwendal Roué wrote: >>> Le 26 avr. 2016 à 07:17, Chris Lattner a écrit : >>> >>> On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution >>> wrote: Here are two things to improve the proposal and

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

On Apr 25, 2016, at 10:48 PM, Gwendal Roué wrote: >> Le 26 avr. 2016 à 07:17, Chris Lattner a écrit : >> >> On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution >> wrote: >>> Here are two things to improve the proposal and make it more clear: >>> >>> I'd like the Motivation section t

Re: [swift-evolution] multi-line string literals.

On Apr 25, 2016, at 5:22 PM, Brent Royal-Gordon wrote: >>> 3. It might be useful to make multiline `"` strings trim trailing >>> whitespace and comments like Perl's `/x` regex modifier does. >> >> If you have modifier characters already, it is easy to build a small zoo >> full of these useful b

Re: [swift-evolution] multi-line string literals.

"""Just in my opinion: having to start each line with a particular token kinda defeats the purpose of multiline string literals. "can't we just continue" "the literal on the next line anyways," "like in C?" "or maybe the "+ "at the end of the line can be"+ "optimized away?" """ What is wrong with

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

> Le 26 avr. 2016 à 07:17, Chris Lattner a écrit : > > On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution > wrote: >> Here are two things to improve the proposal and make it more clear: >> >> I'd like the Motivation section to be much more explicit. I get the argument >> of ambigu

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

I didn’t initially think I would care much one way or the other about this proposal, but I find that proposal 0001 has been really helpful in letting me use prepositions such as “for” and “in” as argument labels and I see the same natural applications in this proposal. I think this does fit in

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

I am very glad to see that Swift protocols will not support optional requirements. I wonder, however, if @objc is the wrong label. The requirement is less because of Objective-C and more because of Cocoa/Cocoa Touch APIs. I wonder if it’s useful to separate which things are being implemented be

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

On Apr 25, 2016, at 9:41 PM, Gwendal Roué via swift-evolution wrote: > Here are two things to improve the proposal and make it more clear: > > I'd like the Motivation section to be much more explicit. I get the argument > of ambiguity, OK, but I don't see the problems it creates. I personally d

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

> * What is your evaluation of the proposal? I think this proposed solution doesn't really address the problem. An @objcOptional keyword is intended to make it clear that the feature is fundamentally, intrinsically, for Objective-C compatibility. Separating the keywords doesn't do that; i

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

> Note that, if we do the above, I’d love to make it an error to define a new > associated type with the same name as an associated type in an inherited > protocol. It’s odd that we do so, and IIRC the only use case for it is to add > requirement to an “existing” associated type. You also do it

Re: [swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

> The review of "Allow (most) keywords in member references" begins now and > runs through April 29th. The proposal is available here: > > > https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md The whole rigamarole would be overkill, so: Absolutely. I see

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 25, 2016, at 8:39 PM, Russ Bishop via swift-evolution > wrote: > > There aren’t enough +1s in the world for this, I fully endorse your proposal > and would like to subscribe to your newsletter ;) > > Do you envision the apinotes will be the vehicle for performing the bridging > sinc

Re: [swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

Hello, Here are two things to improve the proposal and make it more clear: I'd like the Motivation section to be much more explicit. I get the argument of ambiguity, OK, but I don't see the problems it creates. I personally did not have any trouble yet, and this section does not enlighten me. D

[swift-evolution] SE-0069: Mutability and Foundation Value Types

Normally I write more about these but my immediate response to this one is “Why isn’t this in Swift right now please give it to me please ship it yes." ___ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/sw

[swift-evolution] [Review] SE-0066: Standardize function type argument syntax to require parentheses

Hello Swift community, The review of SE-0066 "Standardize function type argument syntax to require parentheses" begins now and runs through May 2, 2016. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0066-standardize-function-type-syntax.md Review

[swift-evolution] [Review] SE-0071: Allow (most) keywords in member references

Hello Swift community, The review of "Allow (most) keywords in member references" begins now and runs through April 29th. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0071-member-keywords.md Reviews are an important part of the Swift ev

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Is that bad? We already have conditional inheritance in classes: class Foo : Bar {} If you move the where clause to the right: class Foo : Bar {} And drop the generic arguments: class Foo : Bar where _constraint_ {} The only difference is “protocol” vs “class”. - Dave Swee

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPhone > On Apr 25, 2016, at 8:41 PM, Dmitri Gribenko wrote: > > On Mon, Apr 25, 2016 at 8:28 PM, Douglas Gregor via swift-evolution > wrote: >> Did you consider an alternate syntax that puts the where clause outside the >> braces, e.g., >> >> protocol R : Q where AssocType : P

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

On Mon, Apr 25, 2016 at 8:28 PM, Douglas Gregor via swift-evolution wrote: > Did you consider an alternate syntax that puts the where clause outside the > braces, e.g., > > protocol R : Q where AssocType : P { > // … > } To me this reads like declaring a conditional conformance. Dmitri -- ma

Re: [swift-evolution] Mutability for Foundation types in Swift

There aren’t enough +1s in the world for this, I fully endorse your proposal and would like to subscribe to your newsletter ;) Do you envision the apinotes will be the vehicle for performing the bridging since ObjectiveCBridgeable was deferred? I actually haven’t checked if that was merged but

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0069: Mutability and Foundation Value Types

Comments: - The sentences "These new struct types will be implemented in the Swift overlay. Immutable/mutable pairs (e.g. Data and MutableData) will become one mutable struct type” are a duplicate and may be a copy/paste error. - I am unsure when a new struct type contains a mutable or immutabl

Re: [swift-evolution] Ability to mark a class as publicly final while remaining internally non-final

> On 25 Apr 2016, at 3:08 PM, Thorsten Seitz via swift-evolution > wrote: > > I think the underlying problem is that you cannot "internally" conform to the > internal protocol. > > Desirable would be something like the following: > > public class SomePublicClass: internal SomeInternalProtoco

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

> On Apr 24, 2016, at 1:34 PM, David Hart via swift-evolution > wrote: > > I wrote the proposal which was discussed to introduce generic constraints for > associated types. I’d like to get some feedback on it and get it ready before > submitting it: > > More Powerful Constraints for Associat

Re: [swift-evolution] Warning for vacuously complying to an all-optional protocol.

> On Apr 25, 2016, at 3:37 PM, William Shipley via swift-evolution > wrote: > > The Swift 2.2 manual says: > > NOTE > > Strictly speaking, you can write a custom class that conforms to > CounterDataSource without implementing either protocol requirement. They are > both optional, after all.

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

> On Apr 25, 2016, at 12:18 PM, James Froggatt via swift-evolution > wrote: > > Eliminating optional protocol requirements is fine by me. The proposal > mentions ‘correcting’ the optional protocol requirement pattern by changing > the methods to optional closure properties, but my feeling is

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

On Apr 25, 2016, at 7:15 PM, Xiaodi Wu via swift-evolution wrote: > > Yup, we're going to try to touch base, the authors of the current draft that > is, sometime this week. More to come, hopefully. > > > On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via swift-evolution > mailto:swift-evolut

Re: [swift-evolution] Localization support for string interpolation

> On Apr 25, 2016, at 7:15 PM, Brent Royal-Gordon via swift-evolution > wrote: > >> I believe I also had concerns about this design because it needlessly >> misses opportunities for compile-time type safety. There doesn't seem >> to be any reason to embed the format specifier in a dynamic strin

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 25, 2016 at 8:25 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams > wrote: > > > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > > > Quick thought: > > > > > > Why are you reaching for the "form..."

Re: [swift-evolution] swift generics not generic enough?

Baojun Wang via swift-evolution writes: > Hi List, > > I'm very new to swift, and feel quite excited about the features provided by > swift. Hi Baojun, Regarding generic features, I recommend reading the Manifesto from Douglas Gregor: http://article.gmane.org/gmane.comp.lang.swift.evolution/8

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 25 2016, Xiaodi Wu wrote: > On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating methods > when > there > > are clear verb cou

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

Yup, we're going to try to touch base, the authors of the current draft that is, sometime this week. More to come, hopefully. On Mon, Apr 25, 2016 at 8:13 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Mon Apr 11 2016, Dave Abrahams wrote: > > > on Sun Apr 10 2

Re: [swift-evolution] Localization support for string interpolation

> I believe I also had concerns about this design because it needlessly > misses opportunities for compile-time type safety. There doesn't seem > to be any reason to embed the format specifier in a dynamic string that > has to be parsed at runtime. I started drafting a post yesterday making the s

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

on Mon Apr 11 2016, Dave Abrahams wrote: > on Sun Apr 10 2016, Michel Fortin wrote: > >> So if you take this into account, storing the comparator as part of >> the stride makes the cost more predictable: not only there is one >> branch less in `next()`, but you avoid evaluating the condition wh

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

On Mon, Apr 25, 2016 at 6:15 PM, Dave Abrahams wrote: > > on Mon Apr 25 2016, Xiaodi Wu wrote: > > > Quick thought: > > > > Why are you reaching for the "form..." rule for the mutating methods > when there > > are clear verb counterparts? > > location: locate > > successor: succeed > > We're not

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

First, something absent: I'm a little bit concerned by the act that there's no means to convert between different concrete FloatingPoint types. Something like the IntMax mechanism in Swift 2's IntegerType might be useful, though there may be good reasons not to do that. >>> >>>

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 8:45 PM, Xiaodi Wu via swift-evolution > wrote: > > Suggestions re naming of `isLessThanOrEqualTo(_:)`: > "Less-than" can be regarded as a unit. Thus, `isLessThan(_:)` is reasonable. > However, `isEqualTo(_:)` is kind of a stretch, but it could just be > `equals(_:)`. Th

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

> > * What is your evaluation of the proposal? > Improved. Suggestions re naming of `isLessThanOrEqualTo(_:)`: "Less-than" can be regarded as a unit. Thus, `isLessThan(_:)` is reasonable. However, `isEqualTo(_:)` is kind of a stretch, but it could just be `equals(_:)`. Thus, you could hav

Re: [swift-evolution] multi-line string literals.

>> * Disabling escapes: If you use single quotes instead of double quotes, >> backslash escapes are disabled. > > We need a way to disable escapes, but it seems to me that (since it is > orthogonal to the other concerns) that it should not be tied to the “multiple > single quotes” syntax. What

Re: [swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

The diff might be helpful as well: https://github.com/apple/swift-evolution/commit/5015578c019818234f1b33d82ad96b94cb444b1b?short_path=3a8f57a#diff-3a8f57ac6db03a3be35cb05972e95d69 On Mon, Apr 25, 2016 at 4:35 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote: > Hello Swif

Re: [swift-evolution] multi-line string literals.

> To audition Xcode using the following multi-line syntax: > > let xml = " > " > " > " \(author) > " XML Developer's Guide > " Computer > " 44.95 > " 2000-10-01 >

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Mon Apr 25 2016, Xiaodi Wu wrote: > Quick thought: > > Why are you reaching for the "form..." rule for the mutating methods when > there > are clear verb counterparts? > location: locate > successor: succeed We're not using successor(i) anymore, as noted below, and furthermore c.succeed(&i)

[swift-evolution] swift generics not generic enough?

Hi List, I'm very new to swift, and feel quite excited about the features provided by swift. when I tried below example in playground (many of them borrowed from swiftz), I find some swift generics looks wired (to me) (1) When use generics in extension, typealias can refer to generics defined

Re: [swift-evolution] multi-line string literals.

On Apr 25, 2016, at 4:55 AM, Patrick Gili wrote: > My thinking here was two-fold: > 1) Address the need to accommodate the lack of regex literals today, and > 2) Future-proof the proposal to accommodate the eventuality of regex literals. MHO is that regex literals are an essential feature for Swi

[swift-evolution] [Review #2] SE-0067: Enhanced Floating Point Protocols

Hello Swift community, Steve opted to revise his original proposal in order to incorporate great feedback from the original review period. As such, we’re extending the review period in order to get adequate consideration of his new changes. The extended review of "SE-0067: Enhanced Floating P

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0069: Mutability and Foundation Value Types

Enormous +1. This is a no-brainier IMO. I am really happy to see this being tackled in the Swift 3 timeframe. Sent from my iPad > On Apr 25, 2016, at 12:27 PM, Chris Lattner wrote: > > Hello Swift community, > > The review of "SE-0069: Mutability and Foundation Value Types" begins now and

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

on Mon Apr 25 2016, Xiaodi Wu wrote: > Me: > > Unless the functions also return an error, mutating/non-mutating pairs > of functions return Void/Self (or maybe Optional) respectively. > Are there other possibilities? But Swift is pretty unique among > C-family languages in allowing overloaded fu

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

on Mon Apr 25 2016, Haravikk wrote: > On 25 Apr 2016, at 22:53, Dave Abrahams via swift-evolution > wrote: > > on Sat Apr 23 2016, Haravikk wrote: > > On 7 Apr 2016, at 18:54, Dmitri Gribenko via swift-evolution > wrote: > > On Thu, Apr 7, 2016 at 12:20 AM,

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

on Sun Apr 24 2016, Brent Royal-Gordon wrote: >> Regarding how this affects sorting methods though, some people (myself >> included) like the simplicity of being able to do the following: >> >> myArray.sort(>) // If array is of Comparable elements, just throw in >> the operator > > That

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

On Mon, Apr 25, 2016 at 1:32 PM, Stephen Canon via swift-evolution < swift-evolution@swift.org> wrote: > > > On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote: > >> func isEqual(to other: Self) -> Bool > >> func isLess(than other: Self) -> B

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

on Sat Apr 23 2016, Brent Royal-Gordon wrote: > Currently, Comparable looks like this: > > public protocol Comparable : Equatable { > /// A [strict total > order](http://en.wikipedia.org/wiki/Total_order#Strict_total_order) > /// over instances of `Self`. > @warn_u

Re: [swift-evolution] multi-line string literals.

possible improvement, one could allow leading spaces before the "data line token" thus enabling indentation, like so { let str = \\dataahgdfhhfdxfg cvcsffggcfg \\c jggjvhfh fhffhfgxfxgdgfhgj jvhhfhfhcgxgc . . } TedvG > On 25 Apr 2016, at 20:47,

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

Quick thought: Why are you reaching for the "form..." rule for the mutating methods when there are clear verb counterparts? location: locate successor: succeed On Mon, Apr 25, 2016 at 1:24 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Wed Apr 20 2016, Chris La

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

On Mon, Apr 25, 2016 at 5:08 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote: > > on Sun Apr 24 2016, Chris Lattner wrote: > > >> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution < > swift-evolution@swift.org> wrote: > >> > >> > >> > >> Sent from my iPhone

[swift-evolution] Warning for vacuously complying to an all-optional protocol.

The Swift 2.2 manual says: NOTE Strictly speaking, you can write a custom class that conforms to CounterDataSource without implementing either protocol requirement. They are both optional, after all. Although technically allowed, this wouldn’t make for a very good data source. I think it’d be

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

> On 25 Apr 2016, at 22:53, Dave Abrahams via swift-evolution > wrote: > > > on Sat Apr 23 2016, Haravikk > wrote: > >>On 7 Apr 2016, at 18:54, Dmitri Gribenko via swift-evolution >> wrote: >> >>On Thu, Apr 7, 2016 at 12:20 AM, Vladimir.S via sw

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Me: Unless the functions also return an error, mutating/non-mutating pairs of functions return Void/Self (or maybe Optional) respectively. Are there other possibilities? But Swift is pretty unique among C-family languages in allowing overloaded functions that differ only by return type. Besides th

Re: [swift-evolution] [Idea] Bringing the partial/total ordering distinction into Comparable

on Mon Apr 25 2016, Stephen Canon wrote: > On Apr 24, 2016, at 6:08 PM, Xiaodi Wu via swift-evolution > wrote: > > Something else to consider if you insist that all floating point values > must > be "orderable" would be how two NaNs are ordered if they have different > payl

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 6:10 PM, Dave Abrahams via swift-evolution > wrote: > > on Mon Apr 25 2016, Stephen Canon wrote: > >>> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution >>> wrote: >>> >>> A few things… >>> >>> First, something absent: I'm a little bit concerned by

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

on Sun Apr 24 2016, Chris Lattner wrote: >> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution >> wrote: >> >> >> >> Sent from my iPhone > >> >>> On Apr 22, 2016, at 5:56 PM, Xiaodi Wu wrote: >>> >>> Not an expert on Obj-C compatibility in Swift by any means, but this >>> re

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

on Mon Apr 25 2016, Stephen Canon wrote: >> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution >> wrote: >> >> A few things… >> >> First, something absent: I'm a little bit concerned by the act that >> there's no means to convert between different concrete FloatingPoint >> t

Re: [swift-evolution] [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 25, 2016, at 15:16, Jordan Rose via swift-evolution > wrote: > > >> On Apr 25, 2016, at 13:13, Erica Sadun via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> * I believe "near miss" is less important than "intentional override", >> requiring a signature of inten

Re: [swift-evolution] [Idea] Repurpose Void

on Sat Apr 23 2016, Антон Жилин wrote: > SE-0066 disallows Void to be used on left side of function types. > > Some people, including me, argue that Void should be removed altogether, > because: > 1) () is more consistent with curried functions: (Int) -> () -> Double > 2) () follows functional p

Re: [swift-evolution] [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 25, 2016, at 13:13, Erica Sadun via swift-evolution > wrote: > > * I believe "near miss" is less important than "intentional override", > requiring a signature of intent as in inheritance. This is a bit of a tangent, but as far as I know no one has objected to this. It's just that

Re: [swift-evolution] Localization support for string interpolation

on Sun Apr 24 2016, Chris Lattner wrote: >> On Apr 24, 2016, at 2:33 PM, Chris Lattner via swift-evolution > wrote: >> >> >>> On Apr 21, 2016, at 12:42 AM, Daniel Höpfl via swift-evolution > wrote: >>> > >>> Hi there! >>> >>> TL;DR: Here’s my idea for a better localized strings handling in

Re: [swift-evolution] Rewrite imported C function signatures

> On Mar 26, 2016, at 2:00 PM, Brent Royal-Gordon via swift-evolution > wrote: > > If that's all you want, maybe we can have an attribute which says "prefer > this version over that one": > > @preferred(since: 3.0, over: socket(_: Int32, _: Int32, _: Int32) -> > Int32) > func soc

Re: [swift-evolution] [Proposal] More Powerful Constraints for Associated Types

on Mon Apr 25 2016, Dmitri Gribenko wrote: > On Sun, Apr 24, 2016 at 1:34 PM, David Hart via swift-evolution > wrote: >> Currently, associated type declarations can only express simple inheritance >> constraints and not the more sophisticated constraints available to generic >> types with the w

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

on Sun Apr 24 2016, Xiaodi Wu wrote: > Anyways, I wouldn’t be surprised if this idea has come up before and has > been rejected, but to me it sounds like a good idea. > > Yes, I suggested this a while back, and it was rejected. That makes it sound much more definitive than anything on t

Re: [swift-evolution] [Proposal] Safer half-open range operator

on Sat Apr 23 2016, "Luis Henrique B. Sousa via swift-evolution" wrote: > No, I got the half-joke on the python-like example. :-) I wasn't joking, really. > I meant the label as part of the brackets content, right before the range > itself. E.g. [truncate: Range] > where "truncate" is the lab

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

on Sat Apr 23 2016, Haravikk wrote: > On 7 Apr 2016, at 18:54, Dmitri Gribenko via swift-evolution > wrote: > > 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 >

Re: [swift-evolution] [Idea] Repurpose Void

> Just wanted to quickly throw out that Kotlin's Unit class, their "equivalent" > of void, semantically follows the definition of "type with only one value" > laid out in the enum Void example above. `enum Void {}` is not a type with only one value; it's a type with no values. -- Brent Royal-

Re: [swift-evolution] [Review] SE-0065 A New Model for Collections and Indices

on Wed Apr 20 2016, Chris Lattner wrote: > On Apr 10, 2016, at 2:41 PM, Chris Lattner > wrote: > > Hello Swift community, > > The review of "A New Model for Collections and Indices" begins now and > runs > through April 18th. The proposal is available here: > > > https://githu

Re: [swift-evolution] Mutability for Foundation types in Swift

> On Apr 25, 2016, at 10:32 AM, Douglas Gregor via swift-evolution > wrote: >> On Apr 25, 2016, at 9:20 AM, Tony Parker via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Brent, >> >> Thanks for your feedback! You’ve got some great questions below, I’ll try to >> answer

Re: [swift-evolution] [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

> On Apr 25, 2016, at 1:13 PM, Erica Sadun wrote: > > With apologies, I do not see near miss checks as a pressing need: > > * Quick Help lists of required members (including associated types and > inherited members) would be far more valuable to me than "near miss" > detection. Understood.

Re: [swift-evolution] Mutability for Foundation types in Swift

Hi Ben, > On Apr 24, 2016, at 3:51 PM, Ben Rimmington via swift-evolution > wrote: > > 0069-swift-mutability-for-foundation.md> > > The proposal looks great. > > ## Introduction > > Broken link: > > --

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 25, 2016, at 11:49 AM, Douglas Gregor wrote: > >> >> On Apr 25, 2016, at 10:13 AM, Erica Sadun > > wrote: >> >> >>> On Apr 25, 2016, at 10:49 AM, Douglas Gregor >> > wrote: * Swift already has an `Optional` type. Importing O

[swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

Hello Swift community, The review of "SE-0069: Mutability and Foundation Value Types" begins now and runs through May 4. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0069-swift-mutability-for-foundation.md Reviews are an important part

[swift-evolution] RFC: Swift Package Manager -- Editable Packages Proposal

I am proposing we change the behavior for iterative development of a group of packages. In particular, we will change the default location to which package dependency sources are cloned, the package managers behavior around those sources, and add a new feature for allowing iterative development.

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

On Apr 25, 2016, at 11:18 AM, Michael Peternell via swift-evolution wrote: > > Is "Self" dynamically dispatched? What would the following program print? > > class A: NSObject { >static func myClassName() -> String { >return "A" >} >func hello() -> String { >return "I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 25, 2016, at 2:12 PM, Jordan Rose wrote: > >> On Apr 22, 2016, at 7:13, Stephen Canon > > wrote: >> >>> /// A signaling NaN (not-a-number). >>> @warn_unused_result >>> static func signalingNaN: Self { get } >>> >>> I’m not sure it really makes sense for a

Re: [swift-evolution] [swift-dev] RFC: "Near-miss" checking for defaulted protocol requirements

With apologies, I do not see near miss checks as a pressing need: * Quick Help lists of required members (including associated types and inherited members) would be far more valuable to me than "near miss" detection. * I'd like the compiler to check for unsatisfied conformances and emit a list

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

I support the approach of making optional requirements ObjC-only. As a nitpick, it feels "wrong" to me to keep a decl modifier around for something that's only a compatibility feature and not natively supported. The proposal notes that a 'objcoptional' modifier was considered and rejected, but w

Re: [swift-evolution] [Review] SE-0069: Mutability and Foundation Value Types

100% in favor of this proposal. IMO, Foundation should feel as natural to use as the Swift standard library; providing native Swift value types to represent many Foundation objects certainly brings us much closer to accomplishing that goal. My only concern is that the Swift wrappers should alw

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

on Mon Apr 25 2016, Radosław Pietruszewski wrote: > Q: Would it be possible to allow some sigil in method names (say, > prefix/postfix > `=`) without any automatic/magic treatment of these methods? Almost anything is possible ;-). > In Ruby, after all, postfix `!` is just allowed in names. It

Re: [swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Sent from my iPhone > On Apr 25, 2016, at 12:37 PM, Joe Groff wrote: > > I support the approach of making optional requirements ObjC-only. As a > nitpick, it feels "wrong" to me to keep a decl modifier around for something > that's only a compatibility feature and not natively supported. The

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 25, 2016, at 11:49 AM, Douglas Gregor via swift-evolution > wrote: > >> (Tangentially, why not introduce a required "override" keyword for >> conforming types that implement a version of a member introduced in protocol >> extensions? This would match the class approach and enhance saf

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0068: Expanding Swift Self to class members and value types

Is "Self" dynamically dispatched? What would the following program print? class A: NSObject { static func myClassName() -> String { return "A" } func hello() -> String { return "I am a \(Self.myClassName())" } } class B: A { static func myClassName() -> String

Re: [swift-evolution] multi-line string literals.

Just wondering - is this currently possible? "multi-line \( //lots of whitespace ) string" It's not especially nice to look at, but maybe using existing syntax would be simpler? From James F ___ swift-evolution mailing list swift-evolution@s

[swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Eliminating optional protocol requirements is fine by me. The proposal mentions ‘correcting’ the optional protocol requirement pattern by changing the methods to optional closure properties, but my feeling is that this ‘solution’ just acts to continue and perhaps encourage the anti-pattern estab

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 25, 2016, at 10:49 AM, Douglas Gregor wrote: >> * Swift already has an `Optional` type. Importing ObjC "optional" protocol >> requirements is therefore semantically problematic from a Swift development >> POV. I don't like either the "@objcoptional" or "@objc optional" solutions >> me

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 25, 2016, at 10:13 AM, Erica Sadun wrote: > > >> On Apr 25, 2016, at 10:49 AM, Douglas Gregor > > wrote: >>> * Swift already has an `Optional` type. Importing ObjC "optional" protocol >>> requirements is therefore semantically problematic from a Swift develop

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

Hello Dave, > That makes these people suspicious of language features that could > threaten to make classes “second-class citizens.” ...and that is unfortunate when emotions and resistance to positive change worsen the discussion, but if you take a look at discussion related to abstract classe

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 23, 2016, at 8:53 PM, Brent Royal-Gordon via swift-evolution > wrote: > > A few things… > > First, something absent: I'm a little bit concerned by the act that there's > no means to convert between different concrete FloatingPoint types. Something > like the IntMax mechanism in Swif

[swift-evolution] [Review] SE-0070: Make Optional Requirements Objective-C only

Hello Swift community, The review of "SE-0070: Make Optional Requirements Objective-C only" begins now and runs through May 2. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0070-optional-requirements.md Reviews are an important part of t

Re: [swift-evolution] Rewrite imported C function signatures

> On Apr 24, 2016, at 3:45 PM, Carlos Rodríguez Domínguez > wrote: > > Thanks for the explanation, which makes me think that it should be suitable, > as you comment, to promote API notes to a “first class” transition technology. > > As a first approach towards that goal, would it be ok to exp

Re: [swift-evolution] mutating/non-mutating suggestion from a Rubyist

on Sat Apr 23 2016, Pyry Jahkola wrote: > I'd like to second James Campbell's suggestion of a `mutate` keyword. > Clarifying > comments inline below: > > On 23 Apr 2016, at 00:24, Dave Abrahams via swift-evolution > wrote: > > This is not a new idea. Something almost identical to t

Re: [swift-evolution] multi-line string literals.

This could be a simple solution: Starting each line with a special token. In the example here it is the \\ double-backslash . when the \\ appears in the first two columns of a source line, this tells the compiler that it is a data line and that more might follow. the last line starting with

Re: [swift-evolution] [Proposal draft] Make Optional Requirements Objective-C-only

> On Apr 24, 2016, at 7:02 PM, Erica Sadun wrote: > > >> On Apr 24, 2016, at 3:28 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Apr 22, 2016, at 8:02 PM, Douglas Gregor via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0067: Enhanced Floating Point Protocols

> On Apr 22, 2016, at 7:13, Stephen Canon wrote: > >> /// A signaling NaN (not-a-number). >> @warn_unused_result >> static func signalingNaN: Self { get } >> >> I’m not sure it really makes sense for a Bignum / APFloat type to support >> such a value. But really I think this is just unde

  1   2   >