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 <[email protected]> wrote: > 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. > > Elia Cereda > > Il giorno 03 nov 2017, alle ore 13:10, Benjamin G via swift-evolution < > [email protected]> ha scritto: > > 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 <[email protected]> > wrote: > >> 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 type of >> the error if we want it. >> >> >> On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution < >> [email protected]> wrote: >> >>> 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 >>> >>> func foo() -> Int‽ { ... } >>> >>> if let x = foo() { >>> // x is Int >>> } else { >>> // somehow access the error >>> } >>> >>> guard let x = foo() else { >>> // Again somehow access the error >>> } >>> >>> func bar() throws -> String { ... } >>> let x = try‽ bar() // x is String‽ >>> let y = x! // y is String >>> >>> // Possibly even make it throw? (just using a random symbol again) >>> let z = try x¡ >>> >>> >>> On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution < >>> [email protected]> wrote: >>> >>>> This is clearly a fine addition to the standard library; even Swift's >>>> Error Handling Rationale (https://github.com/apple/swif >>>> t/blob/master/docs/ErrorHandlingRationale.rst) mentions such an >>>> addition >>>> >>>> What separates standard library types from other types is that they >>>> have language level support, and the wrapping and unwrapping syntax here >>>> could definitely benefit from it (`.unwrap()`--which should be >>>> `.unwrapped()` incidentally--is so much less elegant in comparison to `?` >>>> and `!` for optionals (not that `Result` should use the exact such syntax >>>> for a distinct operation)). It would be a shame to transpose a third-party >>>> `Result` to the standard library without considering if any such tweaks >>>> would substantially improve ergonomics, interconversion with Optional and >>>> throws, etc. >>>> >>>> >>>> On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution < >>>> [email protected]> wrote: >>>> >>>>> Swift-Evolution: >>>>> I’ve written a first draft of a proposal to add Result<T> to the >>>>> standard library by directly porting the Result<T> 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. I’m not >>>>> including it directly in this email, since it includes the full >>>>> implementation and is therefore quite long. (Discourse, please!) >>>>> >>>>> https://github.com/jshier/swift-evolution/blob/master/propos >>>>> als/0187-add-result-to-the-standard-library.md >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jon Shier >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>>> >>> >>> _______________________________________________ >>> 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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
