Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

> On Dec 15, 2017, at 11:39 AM, Howard Lovatt via swift-evolution > wrote: > > +1 > I think the simple solution of if you provide either == or hashValue you have > to provide both is the best approach. Good catch of this bug. That would certainly be a simple rule. However, I think that it's

Re: [swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

> On Dec 15, 2017, at 10:08 AM, Wallacy wrote: > > Is possible to make the compile check what is used inside of == and then > provide the hash value? And if compile cannot check (for whatever reason) > what’s properties is used inside == then raise a compile error? That kind of analysis woul

[swift-evolution] Refining SE-0185: Should providing a custom == suppress the default hashValue?

SE-0185 is awesome, and brings the long-awaited ability for the compiler to provide a default implementation of `==` and `hashValue` when you don't provide one yourself. Doug and I were talking the other day and thought of a potential pitfall: what should happen if you provide a manual implement

Re: [swift-evolution] constant var

> On Dec 14, 2017, at 12:51 AM, Inder Kumar Rathore . > wrote: > > class MyClass { > private var myDict = [String : String]() > > func addMemebr() { > self.myDict["key"] = "value" // Ok for me > } > > func anotherFunc() { > self.myDict = [String : String]() // Not okay fo

Re: [swift-evolution] constant var

> On Dec 11, 2017, at 11:34 PM, Inder Kumar Rathore . via swift-evolution > wrote: > > Hi All, > Today I was writing code and faced a situation where I need to make a > instance variable a const i.e. it shouldn't accept new values from anywhere > but the problem is that I want it's content t

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 29, 2017, at 2:06 PM, Riley Testut wrote: > > >> On Nov 8, 2017, at 11:51 AM, Joe Groff wrote: >> >> In principle it makes sense, but there are implementation challenges we >> didn't have time to consider. It would be nice to make this happen when we >> have the time to make it wo

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 28, 2017, at 8:33 PM, Tony Allevato wrote: > > On Tue, Nov 28, 2017 at 11:23 AM Kelvin Ma via swift-evolution > wrote: > On Tue, Nov 28, 2017 at 12:59 PM, Joe Groff via swift-evolution > wrote: > > > > On Nov 28, 2017, at 10:52 AM, Vladimir.S wrot

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 28, 2017, at 10:52 AM, Vladimir.S wrote: > > On 27.11.2017 20:28, Joe Groff via swift-evolution wrote: >>> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> &g

Re: [swift-evolution] Synthesizing Equatable, Hashable, and Comparable for tuple types

> On Nov 20, 2017, at 5:43 PM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 20, 2017, at 5:39 PM, Kelvin Ma via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> when SE-185 >>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 1:57 PM, Chris Lattner wrote: > > > >>> On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution >>> wrote: >>> >>> so I don't think there's a time constraint forcing us to consider the >>> "narrow" vs "huge" dimension. What's the best thing for the language a

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:52 AM, Xiaodi Wu wrote: > >> On Sat, Nov 11, 2017 at 12:39 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Nov 11, 2017, at 10:12 AM, Chris Lattner wrote: >>> >>> On Nov 11, 2017, at 6:52 AM,

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:33 AM, Chris Lattner wrote: > > > >> On Nov 11, 2017, at 10:15 AM, Joe Groff via swift-evolution >> wrote: >> >> >> >>> On Nov 11, 2017, at 10:04 AM, Chris Lattner wrote: >>> >>>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:12 AM, Chris Lattner wrote: > > On Nov 11, 2017, at 6:52 AM, Joe Groff via swift-evolution > wrote: >>>> I don't think it's that localized. It's going to make call resolution >>>> massively more complicated. Throug

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:04 AM, Chris Lattner wrote: > > > >>> On Nov 11, 2017, at 6:29 AM, Joe Groff via swift-evolution >>> wrote: >>> >>> below the fold as far as the rest of the language is concerned. You could >>> just as w

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

me sort of omni-type enum for the arguments and > return. > > https://stackoverflow.com/questions/196960/can-you-list-the-keyword-arguments-a-python-function-receives > https://docs.python.org/2/c-api/intro.html > > John > >> On 11 Nov 2017, at 16:13, David Hart via s

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 4:21 AM, Marcel Weiher wrote: > > > >> On Nov 10, 2017, at 19:04 , Joe Groff via swift-evolution >> wrote: >> >> I don't like the idea of some calls having wildly different semantics from >> others; > > The obvio

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution >> wrote: >> >> >> >>> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution >>> wrote: >>> >>> Setting this aside, I’m very curiou

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:44 PM, Chris Lattner wrote: > >> On Nov 10, 2017, at 11:42 AM, Joe Groff via swift-evolution >> wrote: >>>> >>>> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >>>> wrote: >>>>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 4:20 PM, Joe Groff wrote: > > > >>> On Nov 10, 2017, at 4:12 PM, Charles Srstka >>> wrote: >>> >>> On Nov 10, 2017, at 5:51 PM, Joe Groff wrote: >>> >>> >>> > On Nov 10, 2017, at 3:45 PM, Charles Srstka > wrote: > > On Nov 10, 2017, at 5:36 PM,

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 4:12 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 5:51 PM, Joe Groff wrote: >> >> >> >>> On Nov 10, 2017, at 3:45 PM, Charles Srstka >>> wrote: >>> On Nov 10, 2017, at 5:36 PM, Joe Groff wrote: How `MyObject.foo(_:bar:)` gets implemented is it

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 3:45 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 5:36 PM, Joe Groff wrote: >> >> How `MyObject.foo(_:bar:)` gets implemented is its own business, as far as >> the compiler is concerned. The compile-time name resolution for the method >> isn't impacted. >> >> -J

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 3:27 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 2:57 PM, Joe Groff wrote: >> >>> On Nov 10, 2017, at 12:37 PM, Charles Srstka >>> wrote: >>> >>>> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-ev

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 12:37 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-evolution >> wrote: >> >> I don't like the idea of some calls having wildly different semantics from >> others; it's difficult eno

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 12:16 PM, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution >> wrote: >> >> Through great pain and community anguish, we pushed ourselves to a model >> where

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 11:20 AM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >> wrote: >> >> This seems a really interesting solution Chris. >> Similar to what Joe mentions I think this would also be appreciated by >

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 10:41 AM, Chris Lattner wrote: > > On Nov 10, 2017, at 10:03 AM, Joe Groff wrote: >> >> I don't like the idea of some calls having wildly different semantics from >> others; it's difficult enough to tell what exactly a call might be doing >> already. > > This isn’t pa

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

I don't like the idea of some calls having wildly different semantics from others; it's difficult enough to tell what exactly a call might be doing already. Since we also lack the more obvious static "Callable" protocol idea to give even well-typed call syntax to user-defined types, this also se

Re: [swift-evolution] Remove AnyObject Constraint for Objective-C Lightweight Generics

> On Nov 8, 2017, at 11:49 AM, Riley Testut via swift-evolution > wrote: > > Hi Swift-Evolution, > > Back when SE-0057 > (https://github.com/apple/swift-evolution/blob/master/proposals/0057-importing-objc-generics.md) > was proposed, it included the following passage: > > • The gener

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:24 PM, Chris Lattner wrote: > > On Oct 4, 2017, at 9:44 AM, Joe Groff wrote: >>> I disagree. The semantics being proposed perfectly overlap with the >>> transitional plan for overlays (which matters for the next few years), but >>> they are the wrong default for anyth

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 5, 2017, at 10:46 AM, Taylor Swift wrote: > > why is runtime dispatch even necessary? Why can’t the client just call the > specialized version directly? Runtime dispatch on the callee side keeps the exact set of specializations open to change, since it isn't ABI, and in theory shoul

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:15 PM, Chris Lattner wrote: > > >> On Oct 4, 2017, at 9:36 AM, Joe Groff > > wrote: >> > It wouldn't avoid the complexity, because we want the "non-ABI, > always-emit-into-client" behavior for the standard library. For the > soon-t

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 4, 2017, at 9:46 AM, Joe Groff via swift-evolution > wrote: > > > > On Oct 3, 2017, at 10:03 PM, Chris Lattner wrote: > >> >>> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: >>> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 10:03 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 10:04 AM, Joe Groff wrote: >> >>> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution >>> wrote: >>> >>> The major question I have is “why yet another attribute”. The thread about >>> exhaustive/ext

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: > > >> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: >> >> >> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution wrote: We have discussed adding a "versioned @inlinable" variant that preserves the pu

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 3, 2017, at 9:59 PM, Slava Pestov wrote: > > > >>> On Oct 3, 2017, at 9:56 PM, Chris Lattner wrote: >>> >>> On Oct 3, 2017, at 9:50 AM, Joe Groff wrote: > On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > > We have

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution wrote: > > The major question I have is “why yet another attribute”. The thread about > exhaustive/extensible enums is similarly proposing introducing another > one-off way to be enums fragile, and this is directly related just fo

Re: [swift-evolution] Get a list of Concrete Implementers for Protocols

> On Oct 3, 2017, at 7:08 AM, Jonathan Hull via swift-evolution > wrote: > > Hi Evolution, > > We talked a while back about being able to get a list of all concrete > implementations for a protocol (i.e. all the types that adhere to it). Is > this still being planned? > > There are a coup

Re: [swift-evolution] Pitch: Cross-module inlining and specialization

> On Oct 2, 2017, at 10:58 PM, Chris Lattner via swift-evolution > wrote: > >> We have discussed adding a "versioned @inlinable" variant that preserves the >> public entry point for older clients, while making the declaration inlinable >> for newer clients. This will likely be a separate pro

Re: [swift-evolution] Pitch: [stdlib] Error recovery hook, PR #12025

> On Sep 21, 2017, at 12:14 AM, John Holdsworth via swift-evolution > wrote: > > Hi S/E, > > I’ve raised a rather speculative PR suggesting a hook be added to stdlib > that would allow users to experiment with error recovery in their apps. > I’ve been asked to put it forward on Swift Evolutio

Re: [swift-evolution] StringProtocol - Do not declare new conformances?

> On Sep 19, 2017, at 3:34 PM, Braden Scothern via swift-evolution > wrote: > > Where I work we are writing a C library for cross platform development on > iOS, Android, and Ubuntu. Part of what I do with this library is wrap it in > Swift. We have a string type that should conform to String

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 7, 2017, at 5:34 PM, Andrew Trick wrote: > >> >> On Sep 7, 2017, at 5:17 PM, Jordan Rose wrote: >> >> >> >>> On Sep 7, 2017, at 17:09, Andrew Trick wrote: >>> >>> On Sep 7, 2017, at 2:29 PM, Jordan Rose wrote: > > We do want the Swift memory model to be cons

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 6, 2017, at 5:31 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 5:17 PM, Taylor Swift wrote: >> >> >> >> On Sep 6, 2017, at 7:01 PM, Andrew Trick wrote: >> >>> On Sep 6, 2017, at 4:54 PM, Taylor Swift wrote: > The semantics of buffer.deallocate() needs to be:

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 7, 2017, at 11:55 AM, Taylor Swift wrote: > > > > On Thu, Sep 7, 2017 at 12:31 PM, Andrew Trick > wrote: > >> On Sep 7, 2017, at 8:06 AM, Taylor Swift > > wrote: >> >> I don’t see any source for this claim in the documentation

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 7, 2017, at 11:57 AM, Taylor Swift wrote: > > > > On Thu, Sep 7, 2017 at 1:39 PM, Jordan Rose > wrote: > > >> On Sep 7, 2017, at 10:31, Andrew Trick via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> >>> On Sep 7, 2017, at 8:06 A

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> >>> > >>> > >>>> On Sep 6, 2017, at 4:31 PM, Joe Groff >>>> <mailto:jgr...@apple.com>> wrote: > >>>> > >>>> > >>>>> On Sep 6, 2017, at 2:28 PM, Andrew Trick >&g

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

, Joe Groff wrote: >>>> >>>> >>>>> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >>>>> >>>>> >>>>>>> On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution >>>>>>> wrote: &

Re: [swift-evolution] Contextualizing async coroutines

> On Sep 2, 2017, at 12:07 PM, Chris Lattner wrote: > > On Aug 31, 2017, at 11:35 AM, Joe Groff via swift-evolution > wrote: >> The coroutine proposal as it stands essentially exposes raw delimited >> continuations. While this is a flexible and expressive feature in t

Re: [swift-evolution] Contextualizing async coroutines

> On Sep 2, 2017, at 1:57 AM, Brent Royal-Gordon wrote: > >> On Aug 31, 2017, at 11:35 AM, Joe Groff via swift-evolution >> wrote: >> >> # Coroutine context >> >> # `onResume` hooks > > `onResume` hooks seem like a really good way to, essent

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 6, 2017, at 3:26 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 2:31 PM, Joe Groff wrote: >> >>> >>> The fact that we’re using malloc and free is already part of the ABI >>> because old libraries need to be able to deallocate memory allocated by >>> newer libraries. >> >> The

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 6, 2017, at 3:07 PM, Taylor Swift wrote: > > > >> On Sep 6, 2017, at 4:31 PM, Joe Groff wrote: >> >> >>> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: >>> >>> >>>>> On Sep 6, 2017, at 1:12 PM, Joe Groff v

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 6, 2017, at 2:28 PM, Andrew Trick wrote: > > >> On Sep 6, 2017, at 1:12 PM, Joe Groff via swift-evolution >> wrote: >> >>> >>> On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: >>> >>> >>> >&g

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> On Sep 6, 2017, at 1:06 PM, Taylor Swift wrote: > > > > On Wed, Sep 6, 2017 at 12:41 PM, Joe Groff via swift-evolution > wrote: > > Currently, memory is deallocated by an instance method on > > UnsafeMutablePointer, deallocate(count:). Like much of the Swif

Re: [swift-evolution] [swift-evolution-announce] [Review] SE-0184: Unsafe[Mutable][Raw][Buffer]Pointer: add missing methods, adjust existing labels for clarity, and remove deallocation size

> Currently, memory is deallocated by an instance method on > UnsafeMutablePointer, deallocate(count:). Like much of the Swift pointer API, > performing this operation on a buffer pointer requires extracting > baseAddress! and count. It is very common for the allocation code above to be > immed

Re: [swift-evolution] Contextualizing async coroutines

> On Aug 31, 2017, at 7:50 PM, Pierre Habouzit wrote: > >> On Aug 31, 2017, at 11:35 AM, Joe Groff via swift-evolution >> wrote: >> >> The coroutine proposal as it stands essentially exposes raw delimited >> continuations. While this is a flexible and ex

Re: [swift-evolution] [Concurrency] A slightly different perspective

> On Aug 31, 2017, at 3:04 PM, Nathan Gray via swift-evolution > wrote: > > I've been following the conversations around Chris Lattner's intriguing > async/await proposal and would like to offer my own take. I feel that the > proposal as written is almost perfect. My suggestions for improvin

[swift-evolution] Contextualizing async coroutines

The coroutine proposal as it stands essentially exposes raw delimited continuations. While this is a flexible and expressive feature in the abstract, for the concrete purpose of representing asynchronous coroutines, it provides weak user-level guarantees about where their code might be running a

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 25, 2017, at 3:54 PM, Logan Shire wrote: > > How would you feel about wrapping the existing functions on > _KVOKeyPathBridgeMachinery: > > @nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:AnyKeyPath) -> > String > @nonobjc fileprivate static func _bridgeKeyPath(_ keyPath:Stri

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 25, 2017, at 1:45 PM, Eagle Offshore wrote: > > >> On Aug 25, 2017, at 1:35 PM, Joe Groff > > wrote: >> >> What do you mean exactly by traits? That's an overloaded term. > > > http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf >

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 25, 2017, at 1:27 PM, Eagle Offshore wrote: > > Reflection mechanisms in general would let one make things like Codable and > Keypaths simply a library capability/protocol extension rather than the > special case one trick pony it is now. > > More than any other feature discussed, fu

Re: [swift-evolution] [Pitch] Improving KeyPath

> On Aug 23, 2017, at 11:18 PM, Logan Shire via swift-evolution > wrote: > > Hey folks! > > Recently I’ve been working on a small library which leverages the Swift 4 > Codable protocol > and KeyPaths to provide a Swift-y interface to CoreData. (It maps back and > forth between > native, imm

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> On Aug 25, 2017, at 12:34 AM, Howard Lovatt wrote: > > In particular a future that is cancellable is more powerful that the > proposed async/await. It's not more powerful; the features are to some degree disjoint. You can build a Future abstraction and then use async/await to sugar code th

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

> On Aug 19, 2017, at 4:56 AM, Jakob Egger via swift-evolution > wrote: > > I've read async/await proposal, and I'm thrilled by the possibilities. Here's > what I consider the canonical example: > @IBAction func buttonDidClick(sender:AnyObject) { > beginAsync { > let image = await proces

Re: [swift-evolution] [Concurrency] do async

> On Aug 21, 2017, at 11:23 PM, Jonathan Hull via swift-evolution > wrote: > > I have seen a lot of examples which use both do and beginAsync: > > beginAsync { > do { > try await foo() > } catch let e { > //Handle Er

Re: [swift-evolution] pure functions

> On Aug 18, 2017, at 12:10 PM, Chris Lattner via swift-evolution > wrote: > > Splitting this out from the concurrency thread: > >> >> On Aug 18, 2017, at 6:12 AM, Matthew Johnson wrote: >>> On Aug 17, 2017, at 11:53 PM, Chris Lattner wrote: >>> In the manifesto you talk about restric

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 23, 2017, at 12:06 AM, Martin Waitz wrote: > > Hello, > >> Am 22.08.2017 um 18:32 schrieb Joe Groff via swift-evolution >> mailto:swift-evolution@swift.org>>: >> The feature provides general delimited continuations. You could write an >> It

Re: [swift-evolution] [Concurrency] Async/Await

> On Aug 21, 2017, at 10:21 PM, David Hart wrote: > > Sorry for the shameless bump :-/ but I’d love to get some answers so I can > better understand the proposal and participate in the discussions. > >> On 21 Aug 2017, at 07:58, David Hart via swift-evolution >> mailto:swift-evolution@swift.o

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 18, 2017, at 12:40 PM, Thomas wrote: > > >> On 18 Aug 2017, at 21:11, Joe Groff wrote: >> >> >>> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution >>> wrote: >>> >>> I think that awaiting on the result of an actor method ends up being pretty >>> similar (in terms o

Re: [swift-evolution] [Concurrency] async/await + actors

> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution > wrote: > > I think that awaiting on the result of an actor method ends up being pretty > similar (in terms of implementation and design tradeoffs) as dispatch_sync. > That said, my understanding is that thread explosion in G

Re: [swift-evolution] [Concurrency] async/await + actors: cancellation

> On Aug 17, 2017, at 11:53 PM, Jan Tuitman via swift-evolution > wrote: > > Hi, > > > After reading Chris Lattners proposal for async/await I wonder if the > proposal has any way to cancel outstanding tasks. > > I saw these two: > > @IBAction func buttonDidClick(sender:AnyObject) { > //

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 11:09 AM, John McCall via swift-evolution > wrote: > >> I think you're right that wrapping errors is tightly related to an effective >> use of typed errors. You can do a reasonable job without language support >> (as has been discussed on the list in the past). On the

Re: [swift-evolution] typed throws

> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution > wrote: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson > > wrote: >> One related topic that isn’t discussed is type errors. Many third party >> libraries use a Result type with typed errors. M

Re: [swift-evolution] typed throws

> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution > wrote: > > Essentially, you give Error a tagged-pointer representation to allow > payload-less errors on non-generic error types to be allocated globally, and > then you can (1) tell people to not throw errors that require allo

Re: [swift-evolution] Retain self in deinit.

> On Jul 21, 2017, at 11:01 AM, Alfred Zien via swift-evolution > wrote: > > Hi! Recently I discovered a way to make a bad access crash in somewhat > unexpected circumstances. Code to reproduce: > > import Foundation > > class Storage { > var val : T? > } > class A { > let s : Storage >

Re: [swift-evolution] [Pitch or bug?] Expanding the capability of `.` prefixed lookup

> On Jun 29, 2017, at 5:19 AM, Matt Gallagher via swift-evolution > wrote: > > Super short summary: > > I think a function argument or right-hand-side expression prefixed with `.` > should allow access to *any* static member on the expected type, dropping the > existing limitations of this s

Re: [swift-evolution] [Pitch] Self's nominal restriction denies significant feature patterns

> On Jun 2, 2017, at 3:08 AM, Zaid Daghestani via swift-evolution > wrote: > > Wow, you’re right. Look like this is a bug? The issue shows up in class > definitions, not protocol definitions. > > This works: > > protocol Selfie { > static func retOne() -> Self > static func r

Re: [swift-evolution] Revisiting SE-0110

> On May 24, 2017, at 6:18 PM, Ben Cohen via swift-evolution > wrote: > > I very much agree with your concerns about this change in general. > > On this specific example, though, I just wanted to point out that there > doesn’t seem to be a good reason to use .forEach here. > > for (key, valu

Re: [swift-evolution] Pitch: Even Smarter KeyPaths?

> On May 15, 2017, at 8:29 AM, Stephen Celis via swift-evolution > wrote: > > I've started to explore Smart KeyPaths in the latest Swift Development > Snapshot with regard to lenses and have been pleasantly surprised: Swift has > one of the better out-of-box optics stories I've come across!

Re: [swift-evolution] Proposal: Allow #if to guard switch case clauses

Seems reasonable to me. > On May 10, 2017, at 1:32 AM, rintaro ishizaki via swift-evolution > wrote: > > Hi evolution community, > > This proposal allows you to enclose switch cases with #if directive. > Implementation: https://github.com/apple/swift/pull/9457 > This is one of the oldest SR i

Re: [swift-evolution] SE-0068 MIA? - Self.classMethod() from instance methods

> On Apr 20, 2017, at 8:13 AM, John Holdsworth via swift-evolution > wrote: > > I was going to have a look at creating a new proposal for this but I see > there already > is one > > and the start of an imple

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 19, 2017, at 3:27 PM, Xiaodi Wu wrote: > > On Wed, Apr 19, 2017 at 5:24 PM, Joe Groff > wrote: > > > On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution > > mailto:swift-evolution@swift.org>> wrote: > > > > We had a very full debate about which way was

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 19, 2017, at 3:16 PM, Xiaodi Wu via swift-evolution > wrote: > > We had a very full debate about which way was superior during review; it was > proposed to behave one way and the core team decided on the other. We have to > let settled decisions be settled: that's the only way Swift

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

thing else. Other common tools like Git already flag trailing whitespace by default, so even if Swift doesn't warn about it, you might still need to satisfy other tools in your pipeline. -Joe > > On Wed, Apr 19, 2017 at 17:02 Joe Groff via swift-evolution > mailto:swift-evolution@

Re: [swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

> On Apr 19, 2017, at 2:43 PM, Adrian Zubarev > wrote: > > First of all, thank you for accepting the proposal. However I still have one > single concern left about the trailing whitespaces. Will the final > implemented version raise a warning or produce an error when there are > trailing whi

[swift-evolution] [Accepted] SE-0168: Multi-Line String Literals

Proposal Link: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Hello Swift Community, The review of SE-0168: "Multi-Line String Literals" ran fr

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 9:47 AM, Gwendal Roué wrote: > > >> Le 18 avr. 2017 à 17:40, Joe Groff a écrit : >> >> >>> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: >>> >>>> >>>> Le 18 avr. 2017 à 06:45, Joe Groff via swif

Re: [swift-evolution] SE-0170: NSNumber bridging and Numeric types

> On Apr 17, 2017, at 5:56 PM, Xiaodi Wu via swift-evolution > wrote: > > It seems Float.init(exactly: NSNumber) has not been updated to behave > similarly? > > I would have to say, I would naively expect "exactly" to behave exactly as it > says, exactly. I don't think it should be a synonym

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 18, 2017, at 1:34 AM, Gwendal Roué wrote: > >> >> Le 18 avr. 2017 à 06:45, Joe Groff via swift-evolution >> a écrit : >> >>> >>> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: >>> >>> >>&g

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 17, 2017, at 9:40 PM, Chris Lattner wrote: > > >> On Apr 17, 2017, at 9:07 AM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution >>> wrote: >>> >>> F

Re: [swift-evolution] [pitch] Comparison Reform

> On Apr 15, 2017, at 9:49 PM, Xiaodi Wu via swift-evolution > wrote: > > For example, I expect `XCTAssertEqual(_:_:)` to be vended > as part of XCTest, in order to make sure that > `XCTAssertEqual(resultOfComputation, Double.nan)` always fails. Unit tests strike me as an example of where yo

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

> On Apr 11, 2017, at 11:24 AM, Drew Crawford wrote: > > > > > On April 11, 2017 at 11:38:05 AM, Joe Groff (jgr...@apple.com > ) wrote: > >> By design, Swift avoids making semantic rules based on that kind of >> analysis, since it would be brittle and difficult to

Re: [swift-evolution] Unify the way properties and methods work to make key-value coding more natural

> On Apr 12, 2017, at 7:48 AM, Andrey Volodin via swift-evolution > wrote: > > Recently I’ve seen some upcoming changes for #keyPath, but the whole things > look a bit messy to me. Today I came up with a simple idea of code > generation, but I thought maybe it would be nice to make this a par

Re: [swift-evolution] switch must be exhaustive, consider adding a default clause

> On Apr 8, 2017, at 11:29 AM, Drew Crawford via swift-evolution > wrote: > > > > Is there a good reason we do not compile this: > > import UIKit > > func foo(operation: UINavigationControllerOperation) { > switch(operation) { > case .push: /* snip */ break > case .pop: /* snip

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 7, 2017, at 12:01 PM, John McCall wrote: > >> On Apr 7, 2017, at 2:50 PM, Joe Groff wrote: >>> On Apr 7, 2017, at 11:48 AM, John McCall wrote: >>> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: > On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution > wrote:

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 7, 2017, at 11:48 AM, John McCall wrote: > >> On Apr 7, 2017, at 1:40 PM, Joe Groff wrote: >>> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution >>> wrote: >>> On Apr 7, 2017, at 12:48 AM, Douglas Gregor wrote: > On Apr 6, 2017, at 9:46 PM, Joh

Re: [swift-evolution] [swift-evolution-announce] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 8:59 PM, John McCall via swift-evolution > wrote: > >> On Apr 5, 2017, at 7:56 PM, Douglas Gregor wrote: >> >> Hello Swift community, >> >> The second review of SE-0161 "Smart KeyPaths: Better Key-Value Coding for >> Swift" begins now and runs through April 9, 2017. The

Re: [swift-evolution] [Review #2] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 7, 2017, at 10:20 AM, John McCall via swift-evolution > wrote: > >> >> On Apr 7, 2017, at 12:48 AM, Douglas Gregor wrote: >> >> >>> On Apr 6, 2017, at 9:46 PM, John McCall wrote: >>> On Apr 7, 2017, at 12:27 AM, Rick Mann wrote: > On Apr 6, 2017, at 20:37 , John McCall

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 2:35 PM, Matthew Johnson wrote: > >> >> On Apr 6, 2017, at 4:22 PM, Joe Groff wrote: >> >>> >>> On Apr 6, 2017, at 2:15 PM, Matthew Johnson wrote: >>> >>> On Apr 6, 2017, at 1:11 PM, Joe Groff wrote: > On Apr 6, 2017, at 11:06 AM, John McCall wr

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 2:15 PM, Matthew Johnson wrote: > > >> On Apr 6, 2017, at 1:11 PM, Joe Groff wrote: >> >> >>> On Apr 6, 2017, at 11:06 AM, John McCall wrote: >>> On Apr 6, 2017, at 1:41 PM, Matthew Johnson wrote: > On Apr 6, 2017, at 12:32 PM, John McCall wrote: >

[swift-evolution] [Review] SE-0168: Multi-Line String Literals

Hello Swift community, The review of SE-0168 "Multi-Line String Literals" begins now and runs through April 12, 2017. The proposal is available here: https://github.com/apple/swift-evolution/blob/master/proposals/0168-multi-line-string-literals.md Reviews are an important part of the Swift evol

Re: [swift-evolution] [Returned for revision] SE-0161: Smart KeyPaths: Better Key-Value Coding for Swift

> On Apr 6, 2017, at 11:06 AM, John McCall wrote: > >> On Apr 6, 2017, at 1:41 PM, Matthew Johnson wrote: >>> On Apr 6, 2017, at 12:32 PM, John McCall wrote: >>> On Apr 5, 2017, at 9:46 PM, Matthew Johnson via swift-evolution wrote: > On Apr 5, 2017, at 7:32 PM, David Smith vi

  1   2   3   4   5   6   7   >