[swift-evolution] ternary operator ?: suggestion

[Andrew Brown]

I agree - but this isn’t the case i covered.
This is the trivial case of an expression

condition ? value1 : value2

which shouldn’t be done using blocks (my example was really an elaboration function)

i know the ternary operator is nice in this case, but isn’t the following just as easy to write and understand ?
it’s certainly easier to add comments - i know it’s a little longer, but … it’s a style thing i guess

func uriEncode(string: String, encodeSlash: Bool) -> String {
  var encodedString = ""
  for char in string.characters {
    if (char >= "A" && char <= "z") || (char >= "a" && char <= "z") || (char >= "0" && char <= "9") || char == "_" || char == "-" || char == "~" || char == "." {
      encodedString += "\(char)"
    }
    else if char == "/" {
      if encodeSlash {
        encodedString += "%2F” // URL Encoding for Forward Slash
      } else {
        encodedString += "\(char)"
      }
    }
    else {
      let literal = String(char)
      for byte in literal.utf8 {
        encodedString += String(format: "%%2X", arguments: [Int(byte)])
      }
    }
  }
  return encodedString
}

however, if you replace the ternary operator with *anything* we’re asking for someone to come along with and change existing multilayered ?: into the new form.

Such as

return (heapAlign  < valueAlign
     ? (valueAlign < elementAlign ? elementAlign : valueAlign)
     : (heapAlign  < elementAlign ? elementAlign : heapAlign))

to

return if heapAlign < valueAlign
    (if valueAlign < elementAlign (elementAlign) else (valueAlign))
  else
    (if heapAlign  < elementAlign (elementAlign) else (heapAlign))

or


return
  if heapAlign < valueAlign (
    if valueAlign < elementAlign (
      elementAlign
    ) else (
      valueAlign
    )
  ) else (
    if heapAlign  < elementAlign (
      elementAlign
    ) else (
      heapAlign
    )
  )

which really doesn’t help - it’s actually easier read as:

return {
  if heapAlign < valueAlign (
    if valueAlign >= elementAlign (
      return valueAlign
    )
  ) else (
    if heapAlign >= elementAlign (
      return heapAlign
    )
  )
  return elementAlign
}()

Use inline blocks for complex logic and the existing else if for trivial cases - even on one or two lines

let width : Int
if highDef {width = 1920} else {width = 720}

if encodeSlash {encodedString += "%2F”} 
else {encodedString += "\(char)"}

ABR.

> On 12 Dec 2015, at 01:31, Drew Crawford via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Strong -1, for all the reasons Andrey gave, although I think his point could benefit from examples.
> 
> Consider this case from my codebase, for which ?: is natural:
> 
>    ///http://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-header-based-auth.html
>   func uriEncode(string: String, encodeSlash: Bool) -> String {
>        var encodedString = ""
>        for char in string.characters {
>            if (char >= "A" && char <= "z") || (char >= "a" && char <= "z") || (char >= "0" && char <= "9") || char == "_" || char == "-" || char == "~" || char == "." {
>                encodedString += "\(char)"
>            }
>            else if char == "/" {
>                encodedString += encodeSlash ? "%2F" : "\(char)"
>            }
>            else {
>                let literal = String(char)
>                for byte in literal.utf8 {
>                    encodedString += String(format: "%%2X", arguments: [Int(byte)])
>                }
>            }
>        }
>        return encodedString
>    }
> 
> I think replacing with `let foo` and scopes lengthens, emphasizes, and draws attention to a very minor detail, de-emphaizing and obscuring the main idea of the function.
> 
> 
> 
> 
> 
>> On Dec 11, 2015, at 7:18 PM, Andrey Tarantsov via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Strong -1; this turns a quick one-liner into a multiline monstrosity. When massaging coordinates and layouts in iOS apps, ?: is often helpful to handle corner cases inline.
>> 
>> A.
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151212/d74ae5a2/attachment-0001.html>