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 > <swift-evolution@swift.org> 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 <benjamin.garrig...@gmail.com > <mailto:benjamin.garrig...@gmail.com>> 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > 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 > <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, 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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/proposals/0187-add-result-to-the-standard-library.md > > <https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md> > > > Thanks, > > Jon Shier > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
