> My intended framing of this does not seem to be coming across in my
> arguments. I am not thinking of this as a way to avoid typing ‘try!’ or
> ‘try?’. This is not intended to replace any of the current uses of ‘throws’.
> Rather, it is intended to replace trapping and nil-returning functions where
> converting it to throw would be burdensome in the most common use cases, but
> still desirable in less common use cases. In my mind, it is only enabling
> the author to provide extra information and flexibility, compared to the
> current behavior.
I'm more or less neutral towards the proposal, but to express my perception,
one part seems similar to the use of "!" in variable declarations (like IB
does):
It just makes force unwrapping (or, here: assuming that no error happened) the
default, but leaves all other options intact.
But Afaics, force unwrapped variables are considered a bad practice that should
be avoided (nearly) wherever possible…
The "try?-replacement" could be more useful for me: In my codebase, I have
several throwing functions paired with computed properties (returning an
Optional of the same type) that directly map to them, and at the call site, I
usually don't care about the error.
I'm not sure if it's useful enough to justify new syntactic sugar for it,
though — especially as I think it's not very intuitive.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
