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

> On Nov 14, 2017, at 19:57, Hooman Mehr wrote: > > You can support all styles with enum as well. My point is precisely that perhaps we should not. While the switch-over-result style is neither better nor worse than the try-catch style, having both in one body of code isn’t

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

Oops, forgot to put the initializers that are the most useful: public init(_ expression: @autoclosure () throws -> T) { do { self = .value(try expression() ) } catch { self = .error(error) } } public init(_ closure: () throws -> T) { do { self = .value(try

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

You can support all styles with enum as well. What don’t you do this: public enum Result { case value(T) case error(Error) public init(_ value: T) { self = .value(value) } public init(error: Error) { self = .error(error) } public func get() throws -> T {

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

For some generic function func doSomething() -> Result You could write (potentially pseudocode); func doSomething() throws -> String { return try doSomething().value() } with Result defined as: enum Result { case success(T) case error(Error) func value() throws -> T { switch self

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

I’m late to this particular party, but having just caught up with the thread I’m surprised that no one substantially addressed the stylistic duality that a `public enum Result` would bring. In short, I’d rather Result be a struct than an enum. I too implemented a Result, for obvious reasons. I

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

> On Nov 6, 2017, at 4:13 AM, Jon Shier wrote: > > This consideration is further complicated by the possible addition of > typed throws in the future. However, the most commonly suggested > implementation fo typed throws keeps the ability for throws to be untyped. >

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

> On Nov 9, 2017, at 3:16 AM, Gwendal Roué via swift-evolution > wrote: > > I wish that the Swift-Evolution discussion around typed / untyped throws > would avoid three traps: > > - a bloodshed between pro and anti typed-throws > - a pro-typed-throws echo chamber

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

> Le 9 nov. 2017 à 08:57, Chris Lattner via swift-evolution > a écrit : > > >> On Nov 6, 2017, at 4:13 AM, Jon Shier > > wrote: >> >> This consideration is further complicated by the possible addition of >> typed

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

> On Nov 6, 2017, at 4:13 AM, Jon Shier > wrote: > > This consideration is further complicated by the possible addition of > typed throws in the future. However, the most commonly suggested > implementation fo typed throws keeps the ability

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

You mention `.unwrap()`. This might be a good time to mention a previous discussion of an `Unwrappable` protocol that provides biased unwrapping and can extend unwrapping syntax to non-Optional types: https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f

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

All: I’ve updated the proposal to include a better introduction and examples of Result usage to better justify its inclusion in the standard library. Re: Result & typed throws This seems to be the most contentious part of this proposal. As explained in the proposal, Result

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

I was thinking the same thing. Typed throws vs `Error` throws are the two major differences between different Result implementations, and they seem somewhat tied from a discussion perspective. I agree with others here, I would like to see this added to the library, and I think it’s a generally

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

> On Nov 3, 2017, at 1:43 PM, Alex Lynch via swift-evolution > wrote: > > Where are the guiding documents for swift's concurrency support? I have an > unrelated idea for the language that I think would be a sizable win for > concurrency. (I won't cross post it

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

Where are the guiding documents for swift's concurrency support? I have an unrelated idea for the language that I think would be a sizable win for concurrency. (I won't cross post it here.) RE Error syntax: Syntactic sugar that makes it easier to ignore errors is a miss-step, I think. Errors

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

Except | is commutative, so you would except Int | Error to be equivalent to Error | Int, which isn't the semantic of the Result type. On Fri, Nov 3, 2017 at 4:04 PM, Elia Cereda wrote: > I'd say that this syntax would be even more coherent with protocol > composition,

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

I'd say that this syntax would be even more coherent with protocol composition, given that x is effectively an Int or an Error: > var x: Int | Error But aside from the specific syntax, I'm pretty sure it isn't the first time this request comes up and there were good reasons for rejecting it.

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

If my memory does not fail, there has also been a discussion about adding a "payload" to the optional types that fit into that context. Something like: //Current enum Optional{ case Some(T) case None } // Adding enum Optional{ case Some(T) case None(Error) //Maybe adding support

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

Actually i'd even prefer : var x: Int ?? Error the spaces makes it more readable, it looks like what you'd do with the ?? operator already, and it seems coherent with the syntax for protocol composition. On Fri, Nov 3, 2017 at 12:12 PM, Benjamin G wrote: > Just

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

To be fair, I would want to see the outcome of the `typed throws` discussion first before moving the discussion about `Result` forward.  Am 3. November 2017 um 04:41:32, Chris Lattner via swift-evolution (swift-evolution@swift.org) schrieb: On Nov 2, 2017, at 11:08 AM, Jon Shier via

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

Just an idea for the type declaration : Why not use the same ? as Optional, but with the type of the error behind : Such as var x: Int?Error Optional Int (Int?) would be seen a special case of Result where the error type is nil. The advantage of this syntax is that it would let us specify the

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

I'm also in favor of providing the ability to specify the type of the error for the result. It provides self-documenting and type safety advantages over the generic Error that really makes the type much more useful. The ideal would be to have the two possible syntax (Result and Result) , but

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

Right, to me there is not a lot of value in adding Result as it exists in AlamoFire. We will (eventually) use the Swift Package Manager for things like this. The value would be in integrating it like Optionals. e.g. (using a strawman symbol) var x: Int‽ = 5 var y: Int‽ = anErrorValue

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

> 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

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

On Thu, Nov 2, 2017 at 9:36 PM, Jon Shier wrote: > > I would argue that a successful addition to the standard library *must* > have such additional justification about why it needs built-in support. If > it's already in use as a third-party library, and you're arguing that the

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

> I would argue that a successful addition to the standard library *must* have > such additional justification about why it needs built-in support. If it's > already in use as a third-party library, and you're arguing that the > third-party design is already quite satisfactory and there's no

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

On Thu, Nov 2, 2017 at 7:04 PM, Jon Shier wrote: > I’m certainly willing to adjust API to better match convention and > guidelines. However, part of the proposal’s basis is the popularity of the > Alamofire implementation (which is rather similar to the antitypical one in >

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

On Thu, Nov 2, 2017 at 7:11 PM, Tony Allevato wrote: > Proposing syntactic sugar for this at the same time would go a long way > toward making me less reluctant to support it. As a type by itself, I don’t > think it holds its weight in the standard library. > > The

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

> On Nov 2, 2017, at 6:19 PM, Dave DeLong wrote: > > > >> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution >> > wrote: >> >> Proposing syntactic sugar for this at the same time would go a long

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

> On Nov 2, 2017, at 6:11 PM, Tony Allevato via swift-evolution > wrote: > > Proposing syntactic sugar for this at the same time would go a long way > toward making me less reluctant to support it. As a type by itself, I don’t > think it holds its weight in the

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

Proposing syntactic sugar for this at the same time would go a long way toward making me less reluctant to support it. As a type by itself, I don’t think it holds its weight in the standard library. The question that I’d want to see answered is, is it possible to make it so that these two

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

I’m certainly willing to adjust API to better match convention and guidelines. However, part of the proposal’s basis is the popularity of the Alamofire implementation (which is rather similar to the antitypical one in regards to additional API offered). Adding special syntax for it

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

This is clearly a fine addition to the standard library; even Swift's Error Handling Rationale ( https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst) mentions such an addition What separates standard library types from other types is that they have language level support,

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

Your point about async and the current work on that side of the language seems convincing to me, however I'd say that Result could also be seing as an improvement over Optional for handling what the "ErrorHandlingRationale.rst" document calls "Simple Domain Errors" (so, not requiring throw), but

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

On Thu, Nov 2, 2017 at 12:41 PM Jon Shier wrote: > This isn’t an argument against Result, it’s an argument against all error > encapsulation in Swift at all. Which is fine for your personal project, but > frankly I don’t see it as a bad thing as a language capability. Like any

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

This isn’t an argument against Result, it’s an argument against all error encapsulation in Swift at all. Which is fine for your personal project, but frankly I don’t see it as a bad thing as a language capability. Like any other use of type-inference, the compiler guarantees you can’t

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

On Thu, Nov 2, 2017 at 12:21 PM Jon Shier wrote: > The Result type I’ve outlined includes the functions necessary to > translate between do try catch and Result. But I fundamentally disagree > with your characterization of Swift’s error handling. At most, Swift > strives to

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

The Result type I’ve outlined includes the functions necessary to translate between do try catch and Result. But I fundamentally disagree with your characterization of Swift’s error handling. At most, Swift strives to hide the line between normal functions and error throwing ones, but

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

I have been writing code in a style that uses explicit effect handling lately. In this style of code, a request describing an async task is returned from a function and later interpreted by a library. When the task completes the library passes the result to completion handler that is part of

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

On Thu, Nov 2, 2017 at 11:58 AM Jon Shier wrote: > You would continue to be free to discourage the usage of Result for > whatever you want. For the rest of us, Result isn’t intended to replace > throws or do/catch, but provide a way to accomplish things in a much more >

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

This is largely unanswerable until that feature is actually designed. However, I can imaging wrapping an async-await in a Result to be easily passed around or transformed. Plus all of the usual non-asynchronous uses of Result in the first place. Jon > On Nov 2, 2017, at 2:52 PM,

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

You would continue to be free to discourage the usage of Result for whatever you want. For the rest of us, Result isn’t intended to replace throws or do/catch, but provide a way to accomplish things in a much more compact and sometimes natural way. As with any API it could be used

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

Key words: “if that is going to change” and I would add “even if it changes would all async use cases map to the new paradigm?”. I understand your concerns, but I am also wary of promised silver bullet solutions that promise or aim to take care of all use cases... Sent from my iPhone > On 2

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

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

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

On Thu, Nov 2, 2017 at 11:32 AM Jon Shier wrote: > That’s been an argument against Result for 2 years now. The usefulness of > the type, even outside of whatever asynchronous language support the core > team comes up with, perhaps this year, perhaps next year, is still very >

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

+1 from me… for what it's worth. The value, in my opinion, is that we won't each have to add result. I would prefer Either but I will take Result. On Thu, Nov 2, 2017 at 2:35 PM, Dave DeLong via swift-evolution < swift-evolution@swift.org> wrote: > > On Nov 2, 2017, at 12:32 PM, Jon Shier

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

> On Nov 2, 2017, at 12:32 PM, Jon Shier wrote: > > That’s been an argument against Result for 2 years now. The usefulness > of the type, even outside of whatever asynchronous language support the core > team comes up with, perhaps this year, perhaps next year, is

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

That’s been an argument against Result for 2 years now. The usefulness of the type, even outside of whatever asynchronous language support the core team comes up with, perhaps this year, perhaps next year, is still very high. Even as something that just wraps throwing functions, or

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

Given that the Swift team is currently working on laying the groundwork for asynchronous APIs using an async/await model, which would presumably tie the throwing cases more naturally into the language than what is possible using completion-closures today, are we sure that this wouldn't duplicate

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

You don’t lose it, it’s just behind `Error`. You can cast out whatever strong error type you need without having to bind an entire type to it generically. If getting a common error type out happens a lot, I usually add a convenience property to `Error` to do the cast for me. Plus, having to

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

I think I’d personally rather see this done with a generic error as well, like: enum GenericResult { case success(T) case failure(E) } And a typealias: typealias Result = GenericResult This would require an “AnyError” type to type-erase a specific

[swift-evolution] Adding Result to the Standard Library

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.