> On Feb 17, 2017, at 10:33 AM, Adrian Zubarev > <[email protected]> wrote: > > Regardless the issue you described with rethrows couldn’t we simply > explicitly tell the compiler the closures type which would include the pure > arrow? > > let _: (T) ~> SomeType = { … } > > That is similar to the behavior we now have with IUOs. (let myView: UIView = > self.view inside UIViewController on iOS) > > I don’t know if the tilde is heavily used in any other programming patterns > and might create confusion here, but from the aesthetic point of view I’d > prefer ~> over =>. > >
Well sure, but then you have just supplied the type annotation. I am describing a specific scenario where an API can accept a function that is pure or a function that is impure and will have the purity of the function passed into it. In many cases such APIs are used with simple closures, often single-expression closures. Our options for determining purity of the closure are: 1. Allow the compiler to infer the purity of these closures. 2. Require an annotation indicating the programmers intent of purity (hopefully one that doesn’t eliminate the conciseness of single-expression closures) We also need a way for the API to indicate it’s conditional purity (something like rethrows). If we don’t have this then we would be forced to write pure and impure overloads when we want to support both and retain the purity when the provided closure is pure. > > > > -- > Adrian Zubarev > Sent with Airmail > > Am 17. Februar 2017 um 15:37:15, Matthew Johnson via swift-evolution > ([email protected] <mailto:[email protected]>) schrieb: > >> Also, what about pure closures that have no need to state a signature >> because it is inferred? This syntactic sugar is a pretty important aspect >> of Swift and often times some of our smallest closures will be pure. For >> example Array’s map should be pure when the closure is pure and many map >> closures are very small. We don’t want to have to annotate these closures >> with a signature. >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
