> On May 2, 2017, at 6:35 AM, Vladimir.S via swift-evolution > <[email protected]> wrote: > On 02.05.2017 8:17, Gor Gyolchanyan via swift-evolution wrote: >> One major thing to keep in mind is how exactly will it behave in generic >> contexts. >> As a similar example, if you can do this: >> func foo<A, B>(pass parameter: A, to closure: (A) -> B) -> B { >> closure(parameter) >> } >> func bar(one: Int, two: Double, three: String) { >> print(“\(one) \(two) \(three)") >> } >> foo(pass: (1, 2.0, “3”), to: bar) > > Sorry for the offtopic in this thread, but could someone clarify the destiny > of SE-0110 > (https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md > > <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md>) > which (when implemented) will disallow this code? > Will SE-0110 be included in Swift 4.0 at all?
To quote from the link: Proposal: SE-0110 <https://github.com/apple/swift-evolution/blob/master/proposals/0110-distingish-single-tuple-arg.md> Authors: Vladimir S., Austin Zheng Review Manager: Chris Lattner <http://github.com/lattner> Status: Implemented (Swift 4) Decision Notes: Rationale <https://lists.swift.org/pipermail/swift-evolution-announce/2016-July/000215.html> Bug: SR-2008 <https://bugs.swift.org/browse/SR-2008> John. > > Gor, also please note that SE-0110 should disallow sending of Void (i.e. () ) > to the function that is defined as function without parameters, i.e. this > should be an error: > func foo() {..} > foo(()) > >> This used to work without generics, but If I’m not mistaken, a proposal was >> accepted to disallow passing tuples and the only argument of a >> multi-argument function, leaving this use case kinda magical. >> This is an enormously useful feature for generic programming (especially >> with the lack of variadic generic types), because this allows us to define >> higher-order functions that operate on any type of function, regardless of >> their arity. >> However we resolve the error issue, it has to behave in a similar way, so >> that throwing and non-throwing functions can be dealt with in a uniform way >> in a generic context without loss of information or security guarantees. >>> On May 2, 2017, at 12:48 AM, Rod Brown <[email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> >>> >>>> On 2 May 2017, at 2:34 am, John McCall <[email protected] >>>> <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>>> wrote: >>>> >>>>> >>>>> On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution >>>>> <[email protected] <mailto:[email protected]> >>>>> <mailto:[email protected] <mailto:[email protected]>>> >>>>> wrote: >>>>> I agree that the key problem with the current architecture that you're >>>>> alluding to is it can't be easily/stored and transferred./Swift errors >>>>> are great for live action but holding and passing after the throwing >>>>> event is problematic, and this is an elegant solution. The storage issue >>>>> is when holding it as a property, and the transferring issue is when >>>>> passing it to a closure as a results of an asynchronous operation etc. >>>>> These are both definitely cases where storage of the type-or-error makes >>>>> perfect sense. >>>>> >>>>> I think the key problem getting this accepted by the Swift Team will be >>>>> that it doesn't currently have any specific use in the standard library. >>>>> As a low level set of types, errors are generated by the lower levels but >>>>> rarely stored, so the Standard library doesn't need the storage. >>>>> Generally the only place we have to do that is in end user code. And >>>>> currently the standard library doesn't have to support asynchronous >>>>> operations natively, so there's nothing inside the kit that would require >>>>> it to do completion handlers with errors. >>>> >>>> We've definitely considered including a Result type, but our sense was >>>> that in an ideal world almost no code would be using it. It's hard to >>>> imagine an ordinary API that ought to be returning a Result rather than >>>> throwing, and once you've defined that away, the major remaining use case >>>> is just to shift computation around, like with a completion handler. That >>>> explicit computation-shifting pattern is something we're hoping to largely >>>> define away with something like C#'s async/await, which would leave Result >>>> as mostly just an implementation detail of such APIs. We didn't want to >>>> spend a great deal of time designing a type that would end up being so >>>> marginal, especially if the changing role would lead us into different >>>> directions on the design itself. We also didn't want to design a type >>>> that would become an obstacle to potential future language changes like, >>>> say, typed throws. >>>> >>>> The downside, of course, is that as long as we lack that async/await >>>> design, computation-shifting isn't real great. >>>> >>>> John. >>> >>> This makes sense and is sensible. I’m curious how such an API would play >>> with the existing NSURLSession completion handlers and the like, but I’m >>> sure the community can design something appropriate. >>> >>> I think the only remaining case is simply storing a result-or-error for >>> later handling, storage to disk, etc. I agree with your contention that the >>> vast majority of the use case for this type is for computation shifting. I >>> think it would and should be rare that we would want to “store” as a >>> variable the “result-or-error” type. Errors should be handled at runtime in >>> the vast majority of cases, presented to the user or otherwise handled, and >>> then moved on from, with the reason no longer being relevant. >>> >>> As you say, in the meantime, it does leave computation-shifting a bit >>> ad-hoc and convoluted, but I think the community has standardized on the >>> Result temporary solution. >>> >>>> >>>>> >>>>> This would therefore be an element in the standard library purely so we >>>>> don't have 50,000 different libraries with 50,000 different result types. >>>>> I'd love to see this standardised so frameworks were more compatible. I'm >>>>> just not sure whether the Core Team would see it as pressing to try and >>>>> officiate a certain type that they themselves don't use. >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
