[swift-evolution] [Pre-Draft] Nil-coalescing and errors

[Yuta Koshizawa]

Hi.

Decoding a JSON is just an example. As I replied to Thorsten, we can
think about various cases we want to unwrap multiple optionals at
once.

This is another example (with the notation `|?` and the postfix
version I proposed instead of the infix `???`).

```
do {
  let sum = try Int(aString)|? + Int(bString)|?
} catch _ {
  // Error handling
}
```

With optional binding, we need to write something like the following.
It needs additional assignments (bindings) to `a` and `b`.

```
if let a = Int(aString), b = Int(bString) {
  let sum = a + b
} else {
  // Error handling
}
```

`Dictionary`'s subscript also returns an optional. Or simply we may
have optional values as properties. We have a lot of optional values
and cases in which we want to pass their unwrapped values directly to
functions. It seems endless to prepare domain-specific solutions for
all of them.

-- Yuta

2016-04-11 3:33 GMT+09:00 Radosław Pietruszewski <radexpl at gmail.com>:
> Just FWIW:
>
> ```
> let foo: Foo? = curry(Foo.init) <^> Int(aString) <*> Int(bString) <*>
> Int(cString)
> ```
>
> But I think it is unreasonable to expect all programmers to understand
> and master it. So I want the postfix `???` or `|?`.
>
>
> I agree. But I would also say that deserializing from JSON is complex enough
> of a problem to warrant a domain-specific solution. There’s a ton of them,
> of course, but for example, with Freddy, it would look something like:
>
> extension Person: JSONDecodable {
>     init(json j: JSON) throws {
>         firstName = try j.string(“firstName”)
>         lastName = try j.string(“lastName”)
>         age = try j.int(“age”)
>     }
> }
>
> let person = try Person(json: json)
>
>
> Even with the proposed `???`, a domain-specific solution would be arguably
> better. So I just don’t consider that a compelling use case.
>
> — Radek
>
> On 09 Apr 2016, at 16:56, Yuta Koshizawa via swift-evolution
> <swift-evolution at swift.org> wrote:
>
> I only wonder whether you really want to repeat Error() all over,
> possibly with `aString` etc. as argument.
>
>
> What I really want is the postfix version of `???` as I wrote in my
> first post in this thread.
>
> Besides the proposed infix `???`, I also want the postfix one which
> throws a `NilError` (something like `struct NilError: ErrorType {}`).
> It is useful to handle multiple `nil`s at once when we are not
> interested in the kind of the error.
>
>
> And also
>
> I think `???` is too long. Instead, I propose `|?`.
> For `foo: Foo?`, `try foo|?` can be read like `Foo` or `nil`. It
> separates (`|`) nil (`?`) from the value and return `Foo`.
> I think it makes sense.
>
>
> Then it becomes something like the following.
>
> ```
> do {
>    let foo: Foo = try foo(
>        a: Int(aString)|?,
>        b: Int(bString)|?,
>        c: Int(cString)|?
>    )
> } catch _ {
>    // Error handling
> }
> ```
>
> I think the infix version is also useful when we actually want to
> specify the types of errors.
>
> Swift provides two ways of error handling: optionals and do/try/catch.
> I think it lacks a way to handle multiple optionals easily in some
> cases. Someone uses applicative styles for it.
>
> ```
> let foo: Foo? = curry(Foo.init) <^> Int(aString) <*> Int(bString) <*>
> Int(cString)
> ```
>
> But I think it is unreasonable to expect all programmers to understand
> and master it. So I want the postfix `???` or `|?`.
>
> -- Yuta
>
>
> 2016-04-08 23:47 GMT+09:00 Thorsten Seitz <tseitz42 at icloud.com>:
>
>
> Am 08.04.2016 um 11:59 schrieb Brent Royal-Gordon <brent at architechies.com>:
>
> I only wonder whether you really want to repeat Error() all over, possibly
> with `aString` etc. as argument.
>
>
> `Error()`, no. `SpimsterKitError.invalidWicketField("a"`), yes, because even
> if `Int.init(_:)` threw *an* error, it wouldn't throw *your* error.
>
>
> That's why I thought that in a real use case that logic would likely be
> extracted.
>
> -Thorsten
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>