[swift-evolution] Proposal Sketch: simplify optional unwrapping syntax

[Al Skipp]

Personally, I wouldn’t like to see any more specialised syntax or compiler voodoo to deal with Optionals. They’re like the Hydra of Swift, though instead of sprouting heads, they sprout new syntax : )

I’d be all for a more generalised approach, ‘do notation’, ‘for comprehensions’, etc – though that’s not likely to happen in the near term (if ever).

> On 11 Dec 2015, at 17:17, Daniel Hooper via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I don't think we should discuss "with" here as that is a separate proposal. I'm trying to draw attention of the approach of Swift generating shadow variables for you when an optional has been proven to be non-null. 
> 
> I didn't say we should remove if/guard let. They would stay.
> 
> My proposal is to improve readability and reduce verbosity by generating shadow variables after "x != nil" checks. The "with x {}" and "if let x {}" approaches only reduce verbosity, at the additional cost of adding new keywords or syntax to the language, and do not really improve readability. Due to this, generating a shadow variable after "x != nil" is the most straightforward, lowest impact and readable approach.
> 
> ilya, you bring up a good point about "create shadow->write to original->read shadow" situations being potentially confusing. However "if let x = x" is very common in situations that this isn't an issue: taking a quick look at my code, 50% of all "if/guard let x = x" are on local variables that cannot possibly change out from under the shadow variable. If that could lead to confusion in a given situation, you could fall back on "if let x = maybe_x" to make it clearer that you're operating on a copy of a variable that won't change out from under you. Alternatively, the "if x != nil { x.bla() }" syntax could only be allowed on optionals in the current function scope.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151211/2f8d018b/attachment.html>