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)
which (when implemented) will disallow this code?
Will SE-0110 be included in Swift 4.0 at all?
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]>> wrote:
On 2 May 2017, at 2:34 am, John McCall <[email protected]
<mailto:[email protected]>> wrote:
On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution
<[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]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
