If using “unwrap” in itself, then it should be statement that only unwraps, hence the
Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Swiftrien Project: http://swiftfire.nl > On 02 Nov 2016, at 02:47, Dany St-Amant via swift-evolution > <[email protected]> wrote: > > >> Le 31 oct. 2016 à 17:44, Erica Sadun via swift-evolution >> <[email protected]> a écrit : >> >> >>> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution >>> <[email protected]> wrote: >>> >>> An alternative that would seem to satisfy some objections is to have a >>> distinct "unwrap" statement--as in: "unwrap x else { ... }". >> >> I'd be against this alternative as it is doing the work of a guard statement >> (including the "must exit scope" rule) with a new keyword and unneeded >> redundancy. >> >> Adding "unwrap" is local. It performs one very common task with added safety >> (avoids unintended shadow effects) and introduces succinctness and clarity. >> In other words, it is a highly focused changed with a measurable benefit in >> use. >> >> Compare: >> >> * "Introduce the unwrap statement that acts like guard but is limited to >> optionals" creates unnecessary language verbosity. >> >> * "guard x else ", meaning "treat optional values differently than all other >> items in a conditional list", fails because it obscures rather than adds >> intent. Worse, it would lead to issues with Boolean optionals whose wrapped >> value is later used within the same condition. >> >> Xiaodi, you mentioned an alternative approach and I'd love a peek at what >> that is. > > Also with the 'guard unwrap', the following code make sense: > > guard unwrap x, x == 10 else { return } > > With a lone unwrap it would not. > > unwrap x, x == 10 else { return } > > I personally do not like shadowing, but a standalone 'unwrap!' could be of > interest to those loving life in the shadows. Beside the shadowing itself, it > should not be any worst than any of the other '!' usage. The feasibility of > such depends of course on how the compiler manages its variable scoping. > > On further thought, if we were to make the, sorry bad word coming, > code-breaking change to disallow legacy shadowing 'let x=x' and force the > shadowing to be done exclusively via this 'unwrap' keyword, it could make it > easier for projects/companies to ban shadowing. > > Dany > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
