Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 12:59 PM, Thorsten Seitz wrote: > > >> Am 10.05.2016 um 18:41 schrieb Timothy Wood via swift-evolution >> : >> >> >>> On May 10, 2016, at 9:28 AM, Matthew Johnson wrote: >>> Yep, understood. It's perfectly clear to me but I understand why Chris is

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

Sent from my iPad > On May 10, 2016, at 11:38 AM, Rick Ballard wrote: > > >>> On May 10, 2016, at 8:49 AM, Matthew Johnson via swift-build-dev >>> wrote: >>> >>> >>> On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution >>> wrote: >>> >>> +1 to `swift package` being a little too v

Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 12:33 PM, Vladimir.S wrote: > > As I understand, please correct me, this proposal will not solve this > problem. The proposed solution just to introduce #Self as replacement for > concrete name of currently declared type. > > And actually I think(I do

Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 11:25 AM, Vladimir.S wrote: > > Thank you for answers, just to clarify: > >> On 10.05.2016 18:47, Matthew Johnson wrote: >> >>> On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution >>> wrote: >>> >>> What about #Self in protocols? I.e. is it

Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 11:12 AM, Timothy Wood wrote: > > >> On May 10, 2016, at 9:05 AM, Matthew Johnson wrote: >> >> It isn't at all the same. Self is covariant with the dynamic context. >> #Self, #Type, #StaticType or whatever we call it is statically determined by >>

Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 11:05 AM, Austin Zheng wrote: > > I'm partial to #This or #ThisType. > Can you elaborate on why? This feels out of place to me in the Swift and Objective-C world. > /bikeshed > > Austin > >> On May 10, 2016, at

Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 10:56 AM, Chris Lattner wrote: > > >> On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution >> wrote: >> >> As a compile-time substitution, it could be used in any and all of the >> examples in your bullet list as a literal text replacement..

Re: [swift-evolution] [RFC] #Self

Sent from my iPad > On May 10, 2016, at 11:01 AM, Timothy Wood via swift-evolution > wrote: > > >>> On May 10, 2016, at 8:56 AM, Chris Lattner via swift-evolution >>> wrote: >>> >>> >>> On May 10, 2016, at 7:50 AM, Erica Sadun via swift-evolution >>> wrote: >>> >>> As a compile-time s

Re: [swift-evolution] [swift-build-dev] [Review] SE-0085: Package Manager Command Names

> On May 10, 2016, at 2:19 AM, Dan Appel via swift-evolution > wrote: > > +1 to `swift package` being a little too verbose. However, I like the > alternative `swift pm`/`swiftpm` (as noted in the proposal) even less. I have > already been referring to the package manager as SPM, so IMO that n

Re: [swift-evolution] [RFC] #Self

> On May 10, 2016, at 10:34 AM, Vladimir.S via swift-evolution > wrote: > > What about #Self in protocols? I.e. is it proposed to have #Self in > protocols, where conformance will require a substitution by real type name? > > protocol A { >func a() -> Self >func b(c: Self) // b(c: #Se

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0086: Drop NS Prefix in Swift Foundation

> What is your evaluation of the proposal? I very much support hoisting types, updating enumerations, and updating the NSStringEncoding constants. I do not support dropping NS on type level names. Dropping the 2 character prefix is a very small benefit and it comes with very real costs. I be

Re: [swift-evolution] [RFC] #Self

> On May 10, 2016, at 9:50 AM, Erica Sadun wrote: > > As a compile-time substitution, it could be used in any and all of the > examples in your bullet list as a literal text replacement.. > > Quick rundown: > > struct A { >...#Self... // #Self is substituted by A > } > > class B { >

Re: [swift-evolution] [RFC] #Self

Can you clarify where would #Self would be allowed? * property declarations * method signatures * method and computed property bodies * all of the above I would like to see this and allowed in all of the above. We should also consider allowing this in protocol requirements. It would not covary

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Sent from my iPad > On May 10, 2016, at 12:53 AM, Andrew Trick wrote: > > >> On May 9, 2016, at 4:07 PM, Matthew Johnson wrote: >> >> I’m also interested in your feedback on whether a proposal around indirect >> is something worth pursuing right now or whether that is something that >> sh

Re: [swift-evolution] Modify optional method semantics for swift

Sent from my iPad > On May 9, 2016, at 5:53 PM, Rod Brown wrote: > > Response inline > > >> On 10 May 2016, at 8:28 AM, Matthew Johnson wrote: >> >> >>> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution >>> wrote: >>> >>> The problem then becomes how do we model such optimizati

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 9, 2016, at 1:03 PM, Andrew Trick wrote: > > >> On May 9, 2016, at 8:34 AM, Matthew Johnson > > wrote: >> >>> I would prefer to wait until indirect structs and improved CoW support have >>> had more discussion. >> >> I've been thinking a lot about Dave

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 8, 2016, at 1:51 AM, Dave Abrahams wrote: > > > on Sat May 07 2016, Andrew Trick wrote: > >>On May 7, 2016, at 2:04 PM, Dave Abrahams wrote: >> >>2. Value types are not "pure" values if any part of the aggregate >>contains a >>reference whose type does n

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 8, 2016, at 1:19 AM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson > wrote: > >>On May 7, 2016, at 4:04 PM, Dave Abrahams wrote: >> >>on Sat May 07 2016, Matthew Johnson wrote: >> >>I've been thinking about this

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 8, 2016, at 12:51 AM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson > wrote: > >>> On May 7, 2016, at 3:03 PM, Dave Abrahams wrote: >>> >>> >>> on Sat May 07 2016, Matthew Johnson wrote: >>> This depends on the type. For t

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 8, 2016, at 1:02 AM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson > wrote: > >>> >>> You haven't answered this question. How would you use this protocol? >> >> I think the best example was given by Andy when discussing pure >> f

Re: [swift-evolution] Modify optional method semantics for swift

> On May 9, 2016, at 5:13 PM, Rod Brown via swift-evolution > wrote: > > This issue I see here, and one that people seem to often forget in > discussions on Swift a Evolution, is that optional methods aren't just used > to change a default value. Their existence often actually changes behavio

Re: [swift-evolution] Dropping NS Prefix in Foundation

> On May 9, 2016, at 12:26 PM, Tony Parker wrote: > > Hi Matthew (and others), > >> On May 9, 2016, at 9:03 AM, Matthew Johnson via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPad >>

Re: [swift-evolution] unums in Swift?

hat > doesn’t actually seem like a good idea to me. This is very much going to be > a jack-of-all-trades, master-of-none situation. Makes sense. Thanks for sharing your thoughts! > > That said, they are an *interesting* idea, so I wouldn’t discourage anyone > from investigating t

Re: [swift-evolution] Dropping NS Prefix in Foundation

Sent from my iPad > On May 9, 2016, at 10:49 AM, Zach Waldowski via swift-evolution > wrote: > > This is exactly the way I see it, too. Many people are coming to Swift > and immediately decrying the language because it doesn't have built-in > support for regex, date parsing, collections beyon

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Sent from my iPad > On May 9, 2016, at 3:01 AM, Andrew Trick wrote: > > >>> On May 7, 2016, at 11:51 PM, Dave Abrahams wrote: >>> >>> Does Array have value semantics then only if T also has value >>> semantics? >> >> This is a great question; I had to rewrite my response four times. >> >>

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Sent from my iPad > On May 9, 2016, at 3:01 AM, Andrew Trick wrote: > > >>> On May 7, 2016, at 11:51 PM, Dave Abrahams wrote: >>> >>> Does Array have value semantics then only if T also has value >>> semantics? >> >> This is a great question; I had to rewrite my response four times. >> >>

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 7:07 PM, Andrew Trick wrote: > > >> On May 7, 2016, at 2:04 PM, Dave Abrahams > > wrote: >> >>> 2. Value types are not "pure" values if any part of the aggregate contains a >>> reference whose type does not have value semantics. >> >> Then Arr

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 3:03 PM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson wrote: > >> This depends on the type. For types representing resources, etc it works just >> fine. But for models it does not work unless the model subgraph is entirely >> immutable and instances are

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 4:04 PM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson > wrote: > >> I've been thinking about this further and can now state my position more >> clearly >> and concisely. >> >> 1. If we're going to have reference types

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 3:53 PM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson wrote: > >> Sent from my iPad >> >> On May 7, 2016, at 2:21 AM, Andrew Trick via swift-evolution >> wrote: >> >>On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution >> wrot

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 3:48 PM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On May 6, 2016, at 8:54 PM, Dave Abrahams wrote: >>> >>> on Fri May 06 2016, Matthew Johnson wrote: On

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 7, 2016, at 3:03 PM, Dave Abrahams wrote: > > > on Sat May 07 2016, Matthew Johnson wrote: > >> This depends on the type. For types representing resources, etc it works just >> fine. But for models it does not work unless the model subgraph is entirely >> immutable and instances are

Re: [swift-evolution] Dropping NS Prefix in Foundation

Sent from my iPad > On May 7, 2016, at 11:14 AM, Tony Parker wrote: > > Hi Matthew, > >> On May 7, 2016, at 5:22 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On May 7, 2016, at 5:03 AM, David Hart via swift-evolution >>> wrote: >>> >>> Hi Tony, >>> >>> I'm very pos

[swift-evolution] unums in Swift?

Unums sound very interesting (http://ubiquity.acm.org/article.cfm?id=2913029). I'm wondering if anyone working on numerics in Swift has considered an implementation in the standard library. Matthew Sent from my iPad ___ swift-evolution mailing list s

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

I've been thinking about this further and can now state my position more clearly and concisely. 1. If we're going to have reference types with value semantics the boundary of the value must extend through the reference to the value of the object. Two instances may have the same logical value s

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Sent from my iPad > On May 7, 2016, at 2:21 AM, Andrew Trick via swift-evolution > wrote: > > >>> On May 6, 2016, at 5:48 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> I don’t mean to imply that it is the *only* valuable >>> property. However, it I (and many others) do believe

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Sent from my iPad > On May 6, 2016, at 11:19 PM, Tyler Fleming Cloutier > wrote: > > >> On May 6, 2016, at 6:54 PM, Dave Abrahams via swift-evolution >> wrote: >> >> >> on Fri May 06 2016, Matthew Johnson wrote: >> >>>On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution >>

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

Sent from my iPad > On May 6, 2016, at 8:54 PM, Dave Abrahams wrote: > > >> on Fri May 06 2016, Matthew Johnson wrote: >> >>On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Thu May 05 2016, Matthew Johnson wrote: >> >>On May 5, 2016, at

Re: [swift-evolution] Dropping NS Prefix in Foundation

Sent from my iPad > On May 7, 2016, at 5:03 AM, David Hart via swift-evolution > wrote: > > Hi Tony, > > I'm very positive about the proposal but I have similar fears, even if less > strong, to David Waite. I agree that the core libraries can be improved with > time, but it's going to be d

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

Sent from my iPad > On May 6, 2016, at 10:10 PM, Andrew Bennett via swift-evolution > wrote: > > Replies inline: > >> On Sat, May 7, 2016 at 12:37 PM, Dave Abrahams via swift-evolution >> wrote: >> >> on Fri May 06 2016, Andrew Bennett wrote: >> >> > Hi Dave, >> > >> > Sorry, Dave, send

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

> On May 6, 2016, at 8:15 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri May 06 2016, Matthew Johnson > wrote: > >>> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Fri May 06 2016, Cole Campbell wrot

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 6, 2016, at 7:48 PM, Dave Abrahams via swift-evolution > wrote: > > > on Thu May 05 2016, Matthew Johnson > wrote: > >>On May 5, 2016, at 10:02 PM, Dave Abrahams >> wrote: >> >>on Thu May 05 2016, Matthew Johnson wrote: >> >>O

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

> On May 6, 2016, at 7:30 PM, Dave Abrahams via swift-evolution > wrote: > > > on Fri May 06 2016, Cole Campbell wrote: > >> I don't know if it's considered too late at this point to rename 'reduce', >> but >> I'll add an enthusiastic +1 to renaming it to 'fold' and adding 'unfold'. >> 'Fo

Re: [swift-evolution] [Proposal] More lenient subscript methods over Collections (was: [Proposal] Safer half-open range operator)

Did you consider making the safer, optional overload the "default" and just omit the label? Sent from my iPad > On May 6, 2016, at 10:23 AM, Luis Henrique B. Sousa via swift-evolution > wrote: > > "bounded" sounds good to me, but I don't know if "optional" is a good choice > as it could be h

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

Sent from my iPad > On May 6, 2016, at 1:29 AM, David Hart via swift-evolution > wrote: > > If we are discussing naming changes to reduce, here's my personal opinion: > > * When I first encountered it, I understood exactly what it did because I > knew that term of art. If it was named seque

Re: [swift-evolution] Making `.self` After `Type` Optional

Definitely +1 to removing the .self requirement. Sent from my iPad > On May 5, 2016, at 11:34 PM, Joe Groff via swift-evolution > wrote: > > To keep progress going on this, I collected my thoughts from March's > discussion into a draft proposal: > > https://github.com/apple/swift-evolution/p

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

Sent from my iPad On May 6, 2016, at 12:52 AM, Brent Royal-Gordon wrote: >> As far as mixed whitespace, I think the only sane thing to do would be to >> only allow leading tabs *or* spaces. Mixing tabs and spaces in the leading >> whitespace would be a syntax error. All lines in the string

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

Sent from my iPad > On May 6, 2016, at 12:14 AM, L. Mihalkovic > wrote: > > Inline > > Regards > (From mobile) > >> On May 6, 2016, at 4:13 AM, Matthew Johnson via swift-evolution >> wrote: >> >> >>>> On May 5, 2016,

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 5, 2016, at 10:02 PM, Dave Abrahams wrote: > > > on Thu May 05 2016, Matthew Johnson > wrote: > >>On May 5, 2016, at 4:59 PM, Dave Abrahams wrote: >> >>on Wed May 04 2016, Matthew Johnson wrote: >> >>On May 4, 2016, at 5:50 PM, D

Re: [swift-evolution] [Review] SE-0073: Marking closures as executing exactly once

> * What is your evaluation of the proposal? +1. I like semantic guarantees provided by the compiler. > * Is the problem being addressed significant enough to warrant a change > to Swift? Yes. > * Does this proposal fit well with the feel and direction of Swift? Yes. > * I

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 5, 2016, at 6:22 PM, Max Moiseev wrote: > > Hi Matthew, > > In general, if you think there is something to be updated in the proposal, it > is worth creating a new revision (like in the floating point protocols > proposal, for example) and mentioning it in the thread. > > I think it

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

> On May 5, 2016, at 8:27 PM, Tyler Cloutier via swift-evolution > wrote: > > >> On May 5, 2016, at 5:08 PM, John Holdsworth via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 5 May 2016, at 14:17, David Hart >> > wrote: >>> >>> On

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 5, 2016, at 4:59 PM, Dave Abrahams wrote: > > > on Wed May 04 2016, Matthew Johnson > wrote: > >>On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution >> wrote: >> >>on Wed May 04 2016, Matthew Johnson wrote: >> >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

Sent from my iPhone > On May 5, 2016, at 5:19 PM, Max Moiseev via swift-evolution > wrote: > > Hi all, > > This email is the result of a discussion between members of the standard > library team. > > We suggest changing the initializers argument label to `exactly` to match the > one used

Re: [swift-evolution] [Accepted with modifications] SE-0045: Add scan, prefix(while:), drop(while:), and unfold to the stdlib

Sent from my iPhone > On May 5, 2016, at 3:40 PM, Erica Sadun via swift-evolution > wrote: > > >>> On May 5, 2016, at 2:39 PM, Chris Lattner wrote: >>> >>> >>> On May 5, 2016, at 1:03 PM, Erica Sadun wrote: >>> On May 4, 2016, at 5:50 PM, Chris Lattner via swift-evolution wr

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 5, 2016, at 2:51 PM, Dave Abrahams wrote: > > > on Thu May 05 2016, Matthew Johnson > wrote: > >> Sent from my iPad >> >>> On May 5, 2016, at 10:59 AM, Dave Abrahams wrote: >>> >>> >>> on Wed May 04 2016, Matthew Johnson wrote: >>> > On Ma

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 5, 2016, at 11:06 AM, Joe Groff via swift-evolution > wrote: > >> >> On May 5, 2016, at 8:56 AM, Dave Abrahams wrote: >> >> >> on Wed May 04 2016, Joe Groff wrote: >> On May 4, 2016, at 5:28 AM, T.J. Usiyan via swift-evolution wrote: Something about your fi

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Sent from my iPad > On May 5, 2016, at 10:59 AM, Dave Abrahams wrote: > > > on Wed May 04 2016, Matthew Johnson wrote: > >>> On May 4, 2016, at 4:16 PM, David Sweeris wrote: >>> >>> Having given it some more thought... Does "PureReference" make >>> sense? What would it mean? At some point

Re: [swift-evolution] Case conventions for mixed-case words (like "iPad" and "NaN")

Sent from my iPad > On May 5, 2016, at 10:41 AM, Jordan Rose via swift-evolution > wrote: > > [resending to include list] > > Hm. I’m not sure why these words would be special, though—if we were going to > use underscores, shouldn’t we consistently go for “snake_case” or something? > +1.

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

t; Int > } > Yep, I know you agree and am happy with the proposal. Just clarifying the rationale (as I see it) for Thorsten. > David. > >> >>> >>> -Thorsten >>> >>> >>>> Am 03.05.2016 um 14:03 sc

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

nts on newly introduced associated types adds clarity and readability IMO. Lookup should only consider inherited protocols. > > -Thorsten > > >> Am 03.05.2016 um 14:03 schrieb Matthew Johnson via swift-evolution >> : >> >> >> >> Sent

Re: [swift-evolution] SE-0080: Failable Numeric Conversion Initializers

Sent from my iPad > On May 5, 2016, at 2:42 AM, William Shipley via swift-evolution > wrote: > > My quibble with this proposal (which should go through in one form or > another) is that the initializers don’t throw. > > I know that this was discussed before, but was this before "try?” was

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 4, 2016, at 6:56 PM, Colin Barrett via swift-evolution > wrote: > >> Swift numeric types all currently have a family of conversion initializers. >> In many use cases they leave a lot to be desired. Initializing an integer >> type with a floating point value will truncate any fraction

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 5:50 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed May 04 2016, Matthew Johnson > wrote: > >>> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution >>> wrote: >>> >>> >>> on Wed May 04 2016, Adrian Zubarev wro

Re: [swift-evolution] [Pitch] Reference equivalent to value-type 'enum'

> On May 4, 2016, at 4:46 PM, Austin Zheng via swift-evolution > wrote: > > Hello swift-evolution: > > Based on recent conversations on the list, I'd like to float a trial balloon: > an "enum class" kind which is analogous to classes in the same way existing > enums are to structs. This is a

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 4:16 PM, David Sweeris wrote: > > Having given it some more thought... Does "PureReference" make sense? What > would it mean? At some point a reference has to, you know, actually refer to > a concrete value. Otherwise it's just turtles all the way down. In my thinking Pur

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 4:20 PM, David Sweeris wrote: > > ... And 30 seconds later I realized that "PureReference" could be fulfilled > by something with only static or computed properties. Any class that only had immutable value semantic members would fulfill PureReference. They would not need

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

onforming types to conform to both AnyReference and AnyValue which would be impossible given your definitions. > Complex restriction might also be possible for whatever desire: > protocol Burger: AnyObject, AnyStruct {} > extension UIView: Burger{} and extension B: Burger {} should wo

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

> On May 4, 2016, at 1:22 PM, Erica Sadun via swift-evolution > wrote: > > Here is a real world example of where I use defaulted parameters: > > public extension UIView { > public convenience init( > _ w: CGFloat, > _ h: CGFloat, > position: CGPoint = .zero, >

Re: [swift-evolution] Should we rename "class" when referring to protocol conformance?

> On May 4, 2016, at 1:29 PM, Dave Abrahams via swift-evolution > wrote: > > > on Wed May 04 2016, Adrian Zubarev wrote: > >> Not sure what to think about the enum cases inside a protocol (if AnyEnum >> would >> even exist), it could be a nice addition to the language, but this is an own >>

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

> On May 4, 2016, at 1:21 PM, David Sweeris via swift-evolution > wrote: > > >> On May 4, 2016, at 11:12, Joe Groff via swift-evolution >> wrote: >> >> I can see value in there being some kind of PureValue protocol, for types >> that represent fully self-contained values, but conforming to

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 3, 2016, at 11:26 PM, Gwendal Roué via swift-evolution > wrote: > >> The review of "SE-0080: Failable Numeric Conversion Initializers" begins now >> and runs through May 9. The proposal is available here: >> >> >> https://github.com/apple/swift-evolution/blob/master/proposals/0

Re: [swift-evolution] [Review] SE-0080: Failable Numeric Conversion Initializers

> On May 3, 2016, at 11:19 PM, Charles Srstka via swift-evolution > wrote: > > Is the proposal to add these initializers to protocols like IntegerType, or > just to individually add them to each of the numeric types? It’s unclear from > the proposal, but in case that question hasn’t been deci

Re: [swift-evolution] [Review] SE-0060: Enforcing order of defaulted parameters

> * What is your evaluation of the proposal? I am unsure. I am definitely not fully convinced yet. I believe a change like this deserves more analysis of the impact of reordering on call site clarity when used with existing APIs. If the argument labels of defaulted parameters in most

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0078: Implement a rotate algorithm, equivalent to std::rotate() in C++

>* What is your evaluation of the proposal? +1. I'm pleased to see an important foundational algorithm added to the standard library. >* Is the problem being addressed significant enough to warrant a change to > Swift? Yes. We should have a standard, shared implementation of as many

Re: [swift-evolution] [Oversight] Reference types allow mutating methods through generics

Sent from my iPad > On May 4, 2016, at 7:28 AM, T.J. Usiyan via swift-evolution > wrote: > > Something about your first paragraph reminded me of a question I've had for a > while. Is there a reasoning behind not being able to restrict a protocol to > value types? One way that this might be

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

Sent from my iPad > On May 3, 2016, at 3:37 AM, Douglas Gregor via swift-evolution > wrote: > > > > Sent from my iPhone > >> On May 2, 2016, at 3:50 PM, David Hart wrote: >> >> Hi Doug, >> >> In the latest version of the proposal, which is now linked to a pull >> request, I mentioned i

Re: [swift-evolution] [Review] SE-0045: Add scan, prefix(while:), drop(while:), and iterate to the stdlib

> On Apr 29, 2016, at 9:44 AM, David Rönnqvist via swift-evolution > wrote: > > >> * What is your evaluation of the proposal? +1 in general, with some reservations about naming. > > +1 This is a useful addition. > > As other have already pointed out, I also feel that `scan` is the lea

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 28, 2016, at 6:20 PM, Erica Sadun wrote: > > >>> On Friday, 29 April 2016, Matthew Johnson via swift-evolution >>> wrote: >>> Does that mean the conformance declaration will be accepted by the compiler >>> under yo

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 28, 2016, at 5:49 PM, Erica Sadun wrote: > > >> On Apr 28, 2016, at 12:18 PM, Matthew Johnson wrote: >> We can't add the keywords if the structs are defined in a module we import >> but don't own. We are only declaring the conformance retroactively. The >> abil

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 28, 2016, at 1:09 PM, Erica Sadun via swift-evolution > wrote: > > Sorry, that's not my question, which doesn't involve protocols I don't own. > Let me restate. Given three types I don't own as follows: > > ``` > struct A : Frobnicate { > override required fun

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

I'm glad you brought this up and provided a clear example Xiaodi. Erica, as I mentioned a few days ago (and Dave A gave +1) this proposal cannot break retroactive modeling if it is going to fly. Can you please update it to clarify how you envision it interacts with retroactive modeling? Would

Re: [swift-evolution] Extending init checks for property initialization

You may wish to have a look at my proposal for partial initializers. It went dormant as I think everyone was burned out on talking about initializers at the time. https://github.com/anandabits/swift-evolution/blob/partial-initializers/proposals/-partial-initializers.md Sent from my iPad

Re: [swift-evolution] [Pitch] Requiring proactive overrides for default protocol implementations.

Sent from my iPad > On Apr 27, 2016, at 3:08 PM, Jérôme ALVES via swift-evolution > wrote: > > What if... > > FooBar.framework defines : > public protocol A { > func foo() > } > public type B: A { > public func foo () { > … implementation … > } > } > > Other module

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

Sent from my iPad > On Apr 27, 2016, at 12:37 AM, Thorsten Seitz via swift-evolution > wrote: > >> Am 26. April 2016 um 22:02 schrieb Dave Abrahams : >> >> >>> on Tue Apr 26 2016, Thorsten Seitz wrote: >>> >>> Am 23.04.2016 um 10:27 schrieb Pyry Jahkola via swift-evolution >>> : >>> >>>

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

> What is your evaluation of the proposal? A somewhat reluctant +1. I like the sugar but Chris makes a good case about the ambiguities and the move away from functional tradition. I am a bit sad about the need for parentheses but it seems like maybe it's for the best. I also must admit that

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] [Proposal] More Powerful Constraints for Associated Types

Sent from my iPad > On Apr 25, 2016, at 9:58 AM, Thorsten Seitz wrote: > > >> Am 25.04.2016 um 15:40 schrieb Matthew Johnson via swift-evolution >> : >> >> I really like this proposal. It is a nice step forward from current state. >> >>

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

I really like this proposal. It is a nice step forward from current state. However, it looks like it doesn't allow us to express constraints that elate two or more associated types together, such as requiring both to have the same Element type. I think it would be a good idea to solve the ge

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

Sent from my iPad > On Apr 19, 2016, at 1:24 PM, David Owens II via swift-evolution > wrote: > > I have a different read of the proposal I guess... I actually find that this: > > (Int, Int) -> (Int, Int) > > Naturally reads take a single pair (e.g. tuple) of (Int, Int) and return a > singl

Re: [swift-evolution] [pitch] Eliminate the "T1 -> T2" syntax, require "(T1) -> T2"

Sent from my iPad > On Apr 19, 2016, at 2:46 AM, Radosław Pietruszewski via swift-evolution > wrote: > > Noo :( > > I understand and appreciate the rationale, uniformity between declaration and > use site being a good thing, but IMHO the proposal just brings unnecessary > noise, far ou

Re: [swift-evolution] [Draft] Expanded min/max algorithms

> On Apr 18, 2016, at 11:08 AM, Dmitri Gribenko wrote: > > On Sun, Apr 17, 2016 at 11:10 AM, Matthew Johnson via swift-evolution > wrote: >> These extension points are effectively “optional protocol requirements”. > > I'm sorry, but they are not optional requirem

Re: [swift-evolution] [Draft] Expanded min/max algorithms

> On Apr 17, 2016, at 9:42 AM, Nate Cook via swift-evolution > wrote: > > > On Apr 17, 2016, at 8:46 AM, plx via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > >> I like the idea. It worries me a bit if the general recipe for such >> situations is to add dedicated-purpose met

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

Sent from my iPad > On Apr 15, 2016, at 6:17 PM, Douglas Gregor wrote: > > >> On Apr 15, 2016, at 4:15 PM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Apr 15, 2016, at 6:03 PM, Douglas Gregor wrote: >>> >>> > On Apr 15, 2016, at 3:55 PM, Matthew Johnson >

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

Sent from my iPad > On Apr 15, 2016, at 6:03 PM, Douglas Gregor wrote: > > >>> On Apr 15, 2016, at 3:55 PM, Matthew Johnson wrote: >>> >>> On Apr 13, 2016, at 11:42 AM, Douglas Gregor wrote: On Apr 11, 2016, at 10:30 AM, Matthew Johnson wrote:

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

> On Apr 13, 2016, at 11:42 AM, Douglas Gregor wrote: > >> >> On Apr 11, 2016, at 10:30 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution >>> wrote: >>> >>> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swi

Re: [swift-evolution] Crypto routines as part of the core library

+1 from me also. I really want to see the community converge on a set of "official" Swifty libraries / modules for everything that is widely used. This doesn't necessarily *need* to be stdlib or corelibs but those are all we have at the moment. While their design leaves something to be de

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

Sent from my iPad > On Apr 11, 2016, at 12:15 PM, Joe Groff via swift-evolution > wrote: > > >> On Apr 7, 2016, at 5:12 PM, Douglas Gregor via swift-evolution >> wrote: >> >> One could perhaps work around (a), (b), and (d) by allowing compound >> (function-like) names like tableView(_:vi

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

Sent from my iPad > On Apr 11, 2016, at 12:03 PM, Dave Abrahams via swift-evolution > wrote: > > > on Sun Apr 10 2016, Dietmar Planitzer wrote: > >>> On Apr 10, 2016, at 11:46, Dave Abrahams via swift-evolution >> wrote: >>> >>> >>> on Sun Apr 10 2016, Dietmar Planitzer >> wrote: >>>

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

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

<    9   10   11   12   13   14   15   16   17   >