> Am 12.04.2016 um 01:01 schrieb 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
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)|?
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 JSO
> 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
Am 08.04.2016 um 11:59 schrieb Brent Royal-Gordon :
>> 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
> 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.
--
Brent Royal-Gordon
Architechies
_
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
A different direction would be to add a non-autoclosure variant to ?? that
explicitly takes a closure.
public func ??(optional: T?, defaultValue: () throws -> T) rethrows -> T {
switch optional {
case .Some(let wrapped): return wrapped
case .None: return try defaultValue()
}
}
Then, the
Of course we can implement a library with `throws` by changing those
properties to methods. However we can think about similar cases.
```
do {
let foo: Foo = try foo(
a: Int(aString) ??? Error(),
b: Int(bString) ??? Error(),
c: Int(cString) ??? Error()
)
} catch _ {
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
> I'd like to see some real-world examples of this before we did anything with
> it.
The following is my real-world example.
```
// Decodes a JSON with SwiftyJSON
do {
let person: Person = try Person(
firstName: json["firstName"].string ??? Error(),
lastName: json["lastName"].string ??
I agree with Sean, I ready use guard and don't see much use in a StdLib or
operator alternative.
Sent from my iPad
> On 06 Apr 2016, at 17:00, Sean Heber via swift-evolution
> wrote:
>
> Interesting, but I’m unsure if all of it is significantly better than just
> using the guard that is effe
> On Apr 6, 2016, at 9:21 AM, Brent Royal-Gordon via swift-evolution
> wrote:
>>> Interesting, but I’m unsure if all of it is significantly better than just
>>> using the guard that is effectively inside of the operator/func that is
>>> being proposed:
>>>
>>> guard let value = Int("NotANumber
I agree with this and I like the operator approach.
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.
```
//
Personally I would like Optional to gain `ifNil` (`??` would call
`ifNil`) and `ifNilThrow`, both of which have an auto closure argument
returning a value and throwing respectively. This would save adding an
extra operator and allow chaining to read better than `??` in some
circumstances, like when
I think I'm with Sean on this one. Optionals and throwing don't have enough to
do with each other to actually come up with a specific operator or method for
this. I can't help but see this as two ideas glued together:
- "By this point in my execution I need a non-optional value, otherwise __
>>> Interesting, but I’m unsure if all of it is significantly better than just
>>> using the guard that is effectively inside of the operator/func that is
>>> being proposed:
>>>
>>> guard let value = Int("NotANumber") else { throw
>>> InitializerError.invalidString }
>>
>> That is a pretty da
I’m inclined to agree with this; the guard statement is fairly clear, though a
slightly cleaner construct for throwing would be nice.
That said, it isn’t mutually exclusive with the MikeAsh alternative provided,
which could still be a nice addition for those that prefer it (though it’s also
a fa
>> Interesting, but I’m unsure if all of it is significantly better than just
>> using the guard that is effectively inside of the operator/func that is
>> being proposed:
>>
>> guard let value = Int("NotANumber") else { throw
>> InitializerError.invalidString }
>>
>
> That is a pretty damn c
> On Apr 6, 2016, at 9:00 AM, Sean Heber wrote:
>
> Interesting, but I’m unsure if all of it is significantly better than just
> using the guard that is effectively inside of the operator/func that is being
> proposed:
>
> guard let value = Int("NotANumber") else { throw
> InitializerError.i
Interesting, but I’m unsure if all of it is significantly better than just
using the guard that is effectively inside of the operator/func that is being
proposed:
guard let value = Int("NotANumber") else { throw InitializerError.invalidString
}
It is only a couple of characters longer and alre
Pyry Jahkola and I have been plugging away on the following which is
preliminary enough not to qualify as an actual draft. He prefers the Mike Ash
approach. I prefer the operator approach. So we have not actually settled on
which one we would actually propose despite how I've written this up.
I
22 matches
Mail list logo
