[swift-evolution] [swift-evolution-announce] [Review] SE-0099: Restructuring Condition Clauses

[Chris Lattner]

> On May 27, 2016, at 4:35 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> I am not a fan of this syntax. `;` reads very strongly as a statement ender to me,

Technically speaking, Swift uses semicolon as a separator, not a line ender.  We already use it to separate multiple expressions on the same line, typically when those expressions are side effecting:

   print(“foo”); print(“bar”)   // silly example

The proposal is consistent with this usage.

> and yet at the same time, it's still visually quite close to `,`. My first impression was that the proposal had an embarrassing typo in the very first example.

Particularly if we end up with Matthew’s proposal to allow omitting the semicolon when it is at the end of the line, I think we’d end up with much nicer looking code in practice.  Here are a couple of random example conditions I pulled from AlamoFire (feel free to pick some of your own):

Now:
     if let
         path = fileURL.path,
         fileSize = try NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as? NSNumber
     {
      

     guard let
            path = fileURL.path
            where NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory: &isDirectory) && !isDirectory else
        {

        if let path = fileURL.path where NSFileManager.defaultManager().fileExistsAtPath(path) {


With SE-0099 + Matthew’s extension, this could be written more nicely as:

     if let path = fileURL.path
        let fileSize = try NSFileManager.defaultManager().attributesOfItemAtPath(path)[NSFileSize] as? NSNumber
     {

     guard let path = fileURL.path
           NSFileManager.defaultManager().fileExistsAtPath(path, isDirectory: &isDirectory)
           !isDirectory else
        {

     if let path = fileURL.path; NSFileManager.defaultManager().fileExistsAtPath(path) {

To be clear, I’m not saying I prefer alamofire’s indentation style :-)


> My suggestion would be to reuse our normal && operator:
> 
> 	guard
> 		x == 0 &&
> 		let y = optional &&
> 		z == 2
> 		else { ... }
> 
> This would obviously be a built-in `&&` separate from our existing, infix operator `&&`.

Yes, this is technically feasible, but it has the opposite problem from the above: && is very closely associated (in terms of programmer mindspace) with boolean conditionals, and the let/case clauses are *not* boolean conditions.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160528/3aa40665/attachment.html>