Re: [swift-evolution] Adding Result to the Standard Library

[Dan Stenmark via swift-evolution]

With the upcoming async-await constructs supporting do-try-catch natively, what 
would the use-case for an explicit Result type be?

Dan

> On Nov 2, 2017, at 11:08 AM, Jon Shier via swift-evolution 
>  wrote:
> 
> Swift-Evolution:
>   I’ve written a first draft of a proposal to add Result to the 
> standard library by directly porting the Result type used in Alamofire to 
> the standard library. I’d be happy to implement it (type and tests for free!) 
> if someone could point me to the right place to do so. I’m not including it 
> directly in this email, since it includes the full implementation and is 
> therefore quite long. (Discourse, please!) 
> 
> https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md
>  
> 
> 
> 
> Thanks, 
> 
> Jon Shier
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

[swift-evolution] [Pitch] Int / Int returns Quotient-Remainder Tuple

[Dan Stenmark via swift-evolution]

(I get the feeling the response to this pitch will be overwhelming negative, 
but *deep inhale* here I go!)

A common mistake I see programmers make is dividing two integers and expecting 
a floating-point result.  This mostly affect new programmers who haven't 
learned about ALUs yet, but I sometimes even see veterans make the mistake when 
they don't realize that neither operand they're passing is floating-point.

let foo = 17 / 5
print( foo )// Huh, why is this 3 and not 3.4?  Oh, wait, I'm an idiot.

I'd like to propose we make '/' operator on two Ints return a 
quotient-remainder tuple by default.  This should help both new and veteran 
programmers alike write less error-prone code.

let (quotient, remainder) = 17 / 5
print( "Q:\(quotient) R:\(remainder)" )// Idiot-proof!

Thoughts?

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

Re: [swift-evolution] [Out of scope][Discussion] Modernize MapKit functions for Swift API Design Guidelines

[Dan Stenmark via swift-evolution]

Swift-evolution is for talking about the core language and its standard 
libraries (String, Array, Optional, etc), not high level frameworks like 
MapKit.  For that, you'll want to file a Radar at http://bugreport.apple.com/ 
.

Dan

> On Jan 1, 2017, at 11:02 AM, Scott Gardner via swift-evolution 
>  wrote:
> 
> Hello Swift Community, and…
> 
> if Calendar.current.identifier == .gregorian {
> print("Happy new year! ")
> }
> 
> I would like to propose that the MapKit framework functions be updated to 
> conform to the Swift API Design Guidelines.
> 
> For example, this is how you would currently determine if the user is 
> currently within the visible map view:
> 
> let userPoint = MKMapPointForCoordinate(mapView.userLocation.coordinate)
> let mapRect = mapView.visibleMapRect
> let inside = MKMapRectContainsPoint(mapRect, userPoint)
> 
> This should be more easily accomplished, such as by doing this:
> 
> let userPoint = mapView.userLocation.coordinate.mapPoint
> let inside = mapView.visibleMapRect.contains(userPoint)
> 
> There are 39 functions that should be updated:
> 
> https://developer.apple.com/reference/mapkit/1612565-mapkit_functions?language=swift
>  
> 
> 
> I realize that this proposal is out of scope for Swift 4. So I will develop 
> it for consideration in a future release, and keep it updated on my fork 
> until it’s ready to submit. All feedback welcomed and appreciated.
> 
> https://github.com/scotteg/swift-evolution/blob/master/proposals/mapkit-functions-for-swift-api-design-guideines.md
>  
> 
> 
> Cheers,
> Scott
> 
> --
> Scott Gardner
> https://github.com/scotteg 
> scotteg.com 
> @scotteg 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Dan Stenmark via swift-evolution]

vin, I think they have accepted that they do not need to enter 
>>>>>> every segment of computing so the extra performance they could get on 
>>>>>> some devices is not worth the risk and the complexity it brings. Not 
>>>>>> everyone is trying to cram complex 3D experiences at 60-90+ FPS on a 
>>>>>> console like constrained devices and I guess Rust is not targeting that 
>>>>>> right now :).
>>>>>> 
>>>>>> On Thu, Aug 11, 2016 at 6:12 PM, Kevin Ballard via swift-evolution 
>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>>> For anyone interested in reading more about Rust's decisions, here's two 
>>>>>> links:
>>>>>> 
>>>>>> The email about abandoning segmented stacks: 
>>>>>> https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html 
>>>>>> <https://mail.mozilla.org/pipermail/rust-dev/2013-November/006314.html>
>>>>>> 
>>>>>> The RFC to remove green threading, with motivation: 
>>>>>> https://github.com/aturon/rfcs/blob/remove-runtime/active/-remove-runtime.md
>>>>>>  
>>>>>> <https://github.com/aturon/rfcs/blob/remove-runtime/active/-remove-runtime.md>
>>>>>> 
>>>>>> -Kevin Ballard
>>>>>> 
>>>>>> 
>>>>>> On Tue, Aug 9, 2016, at 01:28 PM, Kevin Ballard wrote:
>>>>>> > The Rust language used to use a green thread model like Go (actually 
>>>>>> > it exposed a configurable threading interface so you could choose 
>>>>>> > green threads or OS threads). It also used segmented stacks like Go 
>>>>>> > did. Over time, Rust ended up dropping the segmented stacks because it 
>>>>>> > significantly complicated FFI without providing much, if any, benefit 
>>>>>> > (and IIRC Go followed suite and dropped segmented stacks somewhere 
>>>>>> > around version 1.5), and then a little while later Rust dropped green 
>>>>>> > threads entirely. If you can find them, there are lots of discussions 
>>>>>> > of the pros and cons that were documented during this process (on 
>>>>>> > mailing lists, in IRC, possibly on Discourse, there's probably at 
>>>>>> > least one post about it in the Rust subreddit, etc). But ultimately, 
>>>>>> > it was determined that keeping this ability significantly complicated 
>>>>>> > the Rust runtime and it provided almost no benefit. The OS is already 
>>>>>> > really good at scheduling threads, and there's no memory savings 
>>>>>> > without segmented stacks (though the OS will map virtual pages for the 
>>>>>> > stack and only allocate the backing physical pages as the memory is 
>>>>>> > touched, so even if you have a 2MB stack, a new thread will only 
>>>>>> > actually allocate something like 8kb). And there are some pretty big 
>>>>>> > downsides to green threads, such as the fact that it significantly 
>>>>>> > complicates the runtime since all I/O everywhere has to be nonblocking 
>>>>>> > and it has to be transparent to the code, and FFI ends up as a major 
>>>>>> > problem (even without segmented stacks), because you have no idea if 
>>>>>> > an FFI call will block. Green threading libraries end up having to 
>>>>>> > allocate extra OS threads just to continue servicing the green threads 
>>>>>> > when the existing threads are potentially blocked in FFI.
>>>>>> >
>>>>>> > So ultimately, green threads really only make sense when you control 
>>>>>> > the entire ecosystem, so you can ensure the whole stack is compatible 
>>>>>> > with green threads and won't ever issue blocking calls, and even there 
>>>>>> > there's not much benefit and there's a lot of complexity involved.
>>>>>> >
>>>>>> > -Kevin Ballard
>>>>>> >
>>>>>> > On Tue, Aug 9, 2016, at 12:04 PM, Dan Stenmark via swift-evolution 
>>>>>> > wrote:
>>>>>> > > I'd like to inquire as to what the Swift team thoughts on Go's 
>>>>>> > > concurrency model are?  I'm not referring to convenience of the 'go' 
>>>>>> > > keyword and nor am I referring to how the language handles Channels, 
>>>>>> > > both of which being what most folks associate with it.  Rather, I'd 
>>>>>> > > like to ask about the language's use of Green Threads and how the 
>>>>>> > > runtime handles the heavy lifting of multiplexing and scheduling 
>>>>>> > > them.  What are some of the strengths and weaknesses the Swift team 
>>>>>> > > sees to Go's approach?
>>>>>> > >
>>>>>> > > Dan
>>>>>> > >
>>>>>> > > (DISCLAIMER: I'm posting this for academic reasons, not as a pitch.  
>>>>>> > > While the Swift team's responses may inform opinions on the matter, 
>>>>>> > > I do not want this to turn into a 'this is how I think Swift should 
>>>>>> > > do concurrency' debate.  That discussion will come when it comes.)
>>>>>> > > ___
>>>>>> > > swift-evolution mailing list
>>>>>> > > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>> > > https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>>> > > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> ___
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>> 
>>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Dan Stenmark via swift-evolution]

> On Aug 10, 2016, at 10:24 PM, Chris Lattner  wrote:
> 
> Hi Dan,
> 
> There are many folks interested in concurrency topics related to this, but we 
> need to stay focused on finishing Swift 3 and then moving on to Swift 4 stage 
> 1 goals.  As that work is cresting, we’ll start discussions of concurrency, 
> and may even be so bold as to start a new mailing list dedicated to the 
> topic, since it is such a wide reaching topic.
> 
> Until we get to that point, please resist the urge to jump ahead :-)
> 
> -Chris

Chris, many apologies if this came across the wrong way!  As I attempted to 
explain in the opening email, I'm inquiring for purely academic reasons and to 
better my understanding of concurrency as part of language design in general, 
not to pitch anything for Swift.  In retrospect, perhaps -users would've been a 
better fit for this question rather than -evolution.


> On Aug 9, 2016, at 1:59 PM, Joe Groff via swift-evolution 
>  wrote:
> 
>> On Aug 9, 2016, at 1:28 PM, Kevin Ballard via swift-evolution 
>>  wrote:
>> 
>> The Rust language used to use a green thread model like Go (actually it 
>> exposed a configurable threading interface so you could choose green threads 
>> or OS threads). It also used segmented stacks like Go did. Over time, Rust 
>> ended up dropping the segmented stacks because it significantly complicated 
>> FFI without providing much, if any, benefit (and IIRC Go followed suite and 
>> dropped segmented stacks somewhere around version 1.5), and then a little 
>> while later Rust dropped green threads entirely. If you can find them, there 
>> are lots of discussions of the pros and cons that were documented during 
>> this process (on mailing lists, in IRC, possibly on Discourse, there's 
>> probably at least one post about it in the Rust subreddit, etc). But 
>> ultimately, it was determined that keeping this ability significantly 
>> complicated the Rust runtime and it provided almost no benefit. The OS is 
>> already really good at scheduling threads, and there's no memory savings 
>> without segmented stacks (though the OS will map virtual pages for the stack 
>> and only allocate the backing physical pages as the memory is touched, so 
>> even if you have a 2MB stack, a new thread will only actually allocate 
>> something like 8kb). And there are some pretty big downsides to green 
>> threads, such as the fact that it significantly complicates the runtime 
>> since all I/O everywhere has to be nonblocking and it has to be transparent 
>> to the code, and FFI ends up as a major problem (even without segmented 
>> stacks), because you have no idea if an FFI call will block. Green threading 
>> libraries end up having to allocate extra OS threads just to continue 
>> servicing the green threads when the existing threads are potentially 
>> blocked in FFI.
>> 
>> So ultimately, green threads really only make sense when you control the 
>> entire ecosystem, so you can ensure the whole stack is compatible with green 
>> threads and won't ever issue blocking calls, and even there there's not much 
>> benefit and there's a lot of complexity involved.
> 
> In addition to FFI, there's also no way for memory-mapped IO to be 
> non-blocking (a page fault can only be handled by the kernel, after all).

This right here is what I was looking for.  Thanks, guys!

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

[swift-evolution] What're the Swift team's thoughts on Go's concurrency?

[Dan Stenmark via swift-evolution]

I'd like to inquire as to what the Swift team thoughts on Go's concurrency 
model are?  I'm not referring to convenience of the 'go' keyword and nor am I 
referring to how the language handles Channels, both of which being what most 
folks associate with it.  Rather, I'd like to ask about the language's use of 
Green Threads and how the runtime handles the heavy lifting of multiplexing and 
scheduling them.  What are some of the strengths and weaknesses the Swift team 
sees to Go's approach?

Dan

(DISCLAIMER: I'm posting this for academic reasons, not as a pitch.  While the 
Swift team's responses may inform opinions on the matter, I do not want this to 
turn into a 'this is how I think Swift should do concurrency' debate.  That 
discussion will come when it comes.)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Dan Stenmark via swift-evolution]

IIRC, one of the main goals in Swift 3 was to further stabilize the language 
spec and *minimize* breakage in future versions, not eliminate potential 
breakage altogether.  Considering the numerous directions Native Concurrency 
can take (Go-style green thread scheduling, async-await, continuation handler 
transforms, etc), it would be much better if that discussion got started first. 
 Asynchronous error handling will likely be a big talking point of said 
discussion anyway.

Dan

> On Jul 14, 2016, at 3:30 PM, Charles Srstka  wrote:
> 
> Right, but since this would affect the Obj-C importer and thus would be a 
> source-breaking change, it would probably not be possible anymore after Swift 
> 3.
> 
> Charles
> 
>> On Jul 14, 2016, at 4:57 PM, Dan Stenmark  
>> wrote:
>> 
>> I’d say it’s a little premature to be talking about this; the team has made 
>> it very clear that the discussion on Native Concurrency in Swift won’t begin 
>> for another couple months.
>> 
>> Dan
>> 
>>> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>>>  wrote:
>>> 
>>> I know it’s late, but I was wondering what the community thought of this:
>>> 
>>> MOTIVATION:
>>> 
>>> With the acceptance of SE-0112, the error handling picture looks much 
>>> stronger for Swift 3, but there is still one area of awkwardness remaining, 
>>> in the area of returns from asynchronous methods. Specifically, many 
>>> asynchronous APIs in the Cocoa framework are declared like this:
>>> 
>>> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
>>> _Nullable, NSError * _Nullable))completionHandler;
>>> 
>>> This will get imported into Swift as something like this:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
>>> 
>>> The intention of this API is that either the operation will succeed, and 
>>> something will be passed in the Bar parameter, and the error will be nil, 
>>> or else the operation will fail, and then the error parameter will be 
>>> populated while the Bar parameter is nil. However, this intention is not 
>>> expressed in the API, since the syntax leaves the possibility that both 
>>> parameters could be nil, or that they could both be non-nil. This forces 
>>> the developer to do needless and repetitive checks against a case which in 
>>> practice shouldn’t occur, as below:
>>> 
>>> doSomething(foo: foo) { bar, error in
>>> if let bar = bar {
>>> // handle success case
>>> } else if let error = error {
>>> self.handleError(error)
>>> } else {
>>> self.handleError(NSCocoaError.FileReadUnknownError)
>>> }
>>> }
>>> 
>>> This results in the dreaded “untested code.”
>>> 
>>> Note that while it is possible that the developer could simply force-unwrap 
>>> error in the failure case, this leaves the programs open to crashes in the 
>>> case where a misbehaved API forgets to populate the error on failure, 
>>> whereas some kind of default error would be more appropriate. The 
>>> do/try/catch mechanism works around this by returning a generic _NilError 
>>> in cases where this occurs.
>>> 
>>> PROPOSED SOLUTION:
>>> 
>>> Since the pattern for an async API that returns an error in the Cocoa APIs 
>>> is very similar to the pattern for a synchronous one, we can handle it in a 
>>> very similar way. To do this, we introduce a new Result enum type. We then 
>>> bridge asynchronous Cocoa APIs to return this Result type instead of 
>>> optional values. This more clearly expresses to the user the intent of the 
>>> API.
>>> 
>>> In addition to clarifying many Cocoa interfaces, this will provide a 
>>> standard format for asynchronous APIs that return errors, opening the way 
>>> for these APIs to be seamlessly integrated into future asynchronous 
>>> features added to Swift 4 and beyond, in a way that could seamlessly 
>>> interact with the do/try/catch feature as well.
>>> 
>>> DETAILED DESIGN:
>>> 
>>> 1. We introduce a Result type, which looks like this:
>>> 
>>> enum Result {
>>> case success(T)
>>> case error(Error)
>>> }
>>> 
>>> 2. Methods that return one parameter asynchronously with an error are 
>>> bridged like this:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Result) -> ())
>>> 
>>> and are used like this:
>>> 
>>> doSomething(foo: foo) { result in
>>> switch result {
>>> case let .success(bar):
>>> // handle success
>>> case let .error(error):
>>> self.handleError(error)
>>> }
>>> }
>>> 
>>> 3. Methods that return multiple parameters asynchronously with an error are 
>>> bridged using a tuple:
>>> 
>>> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
>>> 
>>> and are used like this:
>>> 
>>> doSomething(foo: foo) { result in
>>> switch result {
>>> case let .success(bar, baz):
>>> // handle success
>>> case let .error(error):
>>>  

Re: [swift-evolution] [PITCH] Improved error handling for async Cocoa methods

[Dan Stenmark via swift-evolution]

I’d say it’s a little premature to be talking about this; the team has made it 
very clear that the discussion on Native Concurrency in Swift won’t begin for 
another couple months.

Dan

> On Jul 14, 2016, at 10:54 AM, Charles Srstka via swift-evolution 
>  wrote:
> 
> I know it’s late, but I was wondering what the community thought of this:
> 
> MOTIVATION:
> 
> With the acceptance of SE-0112, the error handling picture looks much 
> stronger for Swift 3, but there is still one area of awkwardness remaining, 
> in the area of returns from asynchronous methods. Specifically, many 
> asynchronous APIs in the Cocoa framework are declared like this:
> 
> - (void)doSomethingWithFoo: (Foo *)foo completionHandler: (void (^)(Bar * 
> _Nullable, NSError * _Nullable))completionHandler;
> 
> This will get imported into Swift as something like this:
> 
> func doSomething(foo: Foo, completionHandler: (Bar?, Error?) -> ())
> 
> The intention of this API is that either the operation will succeed, and 
> something will be passed in the Bar parameter, and the error will be nil, or 
> else the operation will fail, and then the error parameter will be populated 
> while the Bar parameter is nil. However, this intention is not expressed in 
> the API, since the syntax leaves the possibility that both parameters could 
> be nil, or that they could both be non-nil. This forces the developer to do 
> needless and repetitive checks against a case which in practice shouldn’t 
> occur, as below:
> 
> doSomething(foo: foo) { bar, error in
>   if let bar = bar {
>   // handle success case
>   } else if let error = error {
>   self.handleError(error)
>   } else {
>   self.handleError(NSCocoaError.FileReadUnknownError)
>   }
> }
> 
> This results in the dreaded “untested code.”
> 
> Note that while it is possible that the developer could simply force-unwrap 
> error in the failure case, this leaves the programs open to crashes in the 
> case where a misbehaved API forgets to populate the error on failure, whereas 
> some kind of default error would be more appropriate. The do/try/catch 
> mechanism works around this by returning a generic _NilError in cases where 
> this occurs.
> 
> PROPOSED SOLUTION:
> 
> Since the pattern for an async API that returns an error in the Cocoa APIs is 
> very similar to the pattern for a synchronous one, we can handle it in a very 
> similar way. To do this, we introduce a new Result enum type. We then bridge 
> asynchronous Cocoa APIs to return this Result type instead of optional 
> values. This more clearly expresses to the user the intent of the API.
> 
> In addition to clarifying many Cocoa interfaces, this will provide a standard 
> format for asynchronous APIs that return errors, opening the way for these 
> APIs to be seamlessly integrated into future asynchronous features added to 
> Swift 4 and beyond, in a way that could seamlessly interact with the 
> do/try/catch feature as well.
> 
> DETAILED DESIGN:
> 
> 1. We introduce a Result type, which looks like this:
> 
> enum Result {
>   case success(T)
>   case error(Error)
> }
> 
> 2. Methods that return one parameter asynchronously with an error are bridged 
> like this:
> 
> func doSomething(foo: Foo, completionHandler: (Result) -> ())
> 
> and are used like this:
> 
> doSomething(foo: foo) { result in
>   switch result {
>   case let .success(bar):
>   // handle success
>   case let .error(error):
>   self.handleError(error)
>   }
> }
> 
> 3. Methods that return multiple parameters asynchronously with an error are 
> bridged using a tuple:
> 
> func doSomething(foo: Foo, completionHandler: (Result<(Bar, Baz)>) -> ())
> 
> and are used like this:
> 
> doSomething(foo: foo) { result in
>   switch result {
>   case let .success(bar, baz):
>   // handle success
>   case let .error(error):
>   self.handleError(error)
>   }
> }
> 
> 4. Methods that return only an error and nothing else are bridged as they are 
> currently, with the exception of bridging NSError to Error as in SE-0112:
> 
> func doSomething(foo: Foo, completionHandler: (Error?) -> ())
> 
> and are used as they currently are:
> 
> doSomething(foo: foo) { error in
>   if let error = error {
>   // handle error
>   } else {
>   // handle success
>   }
> }
> 
> 5. For the case in part 2, the bridge works much like the do/try/catch 
> mechanism. If the first parameter is non-nil, it is returned inside the 
> .success case. If it is nil, then the error is returned inside the .error 
> case if it is non-nil, and otherwise _NilError is returned in the .error case.
> 
> 6. For the case in part 3, in which there are multiple return values, the 
> same pattern is followed, with the exception that we introduce a new 
> Objective-C annotation. I am provisionally naming this annotation 
> 

Re: [swift-evolution] Winding down the Swift 3 release

[Dan Stenmark via swift-evolution]

With the generics and ABI stability goals getting pushed out to a future 
release, how does that affect the plans for Swift concurrency features?  Will 
the topic still be explored in the Swift 4 timeframe, or do you expect that 
discussion be deferred to 5 or beyond?

Dan

> On May 16, 2016, at 8:18 AM, Chris Lattner via swift-evolution 
>  wrote:
> 
> Hi Everyone,
> 
> As we get deeper into the Swift 3 release cycle, we’re beginning to have a 
> more precise understanding about what the release will shape up to be.  Ted 
> posted details of the Swift 3 release process last week 
> (https://swift.org/blog/swift-3-0-release-process/) and I just updated the 
> main swift-evolution README.md file 
> (https://github.com/apple/swift-evolution) with some updated details about 
> the goals of Swift 3.
> 
> This release is shaping up to be a really phenomenal release that will 
> redefine the feel of Swift and make a major leap towards maturing the Swift 
> language and development experience.  We have had a focus on getting to 
> source stability, with the forward-looking goal of making Swift 4 as source 
> compatible with Swift 3 as we can reasonably accomplish.  It tackled API 
> naming head on (which is one of the hardest problems in computer science 
> [1]), made major improvements to the consistency and feel of the language, 
> and has several nice across the board additions.
> 
> That said, it is also clear at this point that some of the loftier goals that 
> we started out with aren’t going to fit into the release - including some of 
> the most important generics features needed in order to lock down the ABI of 
> the standard library. As such, the generics and ABI stability goals will roll 
> into a future release of Swift, where I expect them to be the *highest* 
> priority features to get done.
> 
> I expect discussion and planning for Swift 3.x and Swift 4 to start sometime 
> around August of this year.  Until then, it is very important that we as a 
> community stay focused on the goals of Swift 3: I’d really prefer us all to 
> resist the urge to discuss major blue sky features for future releases.  We 
> would also like to put a significant amount of effort into bug fixing and 
> quality refinements as well, which means that the core team will be 
> proactively deferring evolution proposals to later releases that don’t align 
> with the Swift 3 goals, especially those that are strictly additive.
> 
> Thank you for all of the amazing community that has developed on this list, 
> it is great to work with you all!  Let us know if you have any questions,
> 
> -Chris
> 
> [1] It is well known that the two hard problems in Computer Science are 
> naming, cache invalidation, and off-by-one errors.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Re: [swift-evolution] Proposal - Allow properties in Extensions

[Dan Stenmark via swift-evolution]

I’d +1 this proposal for extensions existing in the same module as the class 
declaration.  However, creating new properties for classes defined in other 
modules would likely involve side-table lookups, and my understanding is that 
it has some performance implications.  

In cases where you want to extend the storage of a class, consider if maybe a 
subclass is all you need.

Dan

> On Dec 18, 2015, at 11:42 AM, Nutchaphon Rewik via swift-evolution 
>  wrote:
> 
> I only see the benefits on this.
> We don't have to store all states in one file. States can be stored 
> separately. So, we can write code in more composition style.
> We can add new states to the existing type. Not just NSObject subclass with 
> associated object.
> 
> protocol Incrementer{
> func increase()
> }
> 
> extension Incrementer{
> 
> var count = 1 // allows stored properties
> 
> func increase(){
> print(count)
> count = count + 1
> }
>  
> }
> 
> 
> > On Dec 8, 2015, at 10:51 AM, Kevin Kachikian via swift-evolution 
> >  > > wrote:
> > 
> > I’d like to proposal to the Swift community and discuss the advantages and 
> > disadvantages of adding modifiable properties to extensions (in addition to 
> > the already existing computed properties, instance methods, subscripts, 
> > etc.):
> > 
> > extension SomeType {
> > 
> > var aNewProperty: Int
> > var anotherVariable: String
> > var aThirdOne: MyStruct
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution