> On Mar 7, 2017, at 1:31 PM, Jonathan Hull <[email protected]> wrote: > > Would ‘if let foo = foo’ still be allowed? > >
Existing code should to continue to work with `if let foo = foo`. I don't believe I put anything in-text about removing this, but if you see something let me know. -- E >> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> I have been involved in several separate related draft proposals for >> discussions >> that were cut off about 4 months ago. I believe they meet the criteria for >> Stage 2, >> but I'm doing a poor job presenting them coherently on-list. >> >> Because of that, I'm going to start over here, hopefully pulling in all the >> details >> and allowing the community to provide feedback and direction. The following >> gist is an amalgam of work I was discussing with Xiaodi Wu, Chris Lattner, >> and >> David Goodine. >> >> https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f >> <https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f> >> >> I've decided to link to the gist rather than paste the entire proposal as >> that never seems to >> really work here. >> >> >> In a nutshell: >> >> Unwrapping values is one of the most common Swift tasks and it is >> unnecessarily complex. >> >> Consider the following solutions: >> >> Introduce an unwrap keyword for Optional values >> Introduce an Unwrappable protocol for associated-value enumerations. >> Apply unwrap to non-Optional values. >> Extend for and switch. >> Fix pattern match binding issues. >> Simplify complex binding. >> >> <https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f#motivation>Motivation >> >> Unwrapping with conditional binding and pattern matching is unnecessarily >> complex and dangerous: >> >> Using "foo = foo" fails DRY principles >> <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>. >> Using case let .some(foo) = foo or case .some(let foo) = foo fails KISS >> principles <https://en.wikipedia.org/wiki/KISS_principle>. >> Using the = operator fails the Principle of Least Astonishment >> <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>. >> Allowing user-provided names may shadow existing variables without compiler >> warnings. >> The complexity and freedom of let and var placement can introduce bugs in >> edge cases. >> -- E >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
