Isn't that exactly what the nil-coalescing operator ?? does?

    func query(name: String?) -> String {
        return "{ param: \(name ?? "null") }"
    }

If you use the JSONSerialization class from the Foundation library then `nil` 
is bridged to `NSNull` and translated to "null" automatically (see SE-0140).

Regards,
Martin

> Am 08.02.2017 um 15:04 schrieb Maxim Veksler via swift-evolution 
> <[email protected]>:
> 
> Hello, 
> 
> Let's assume I have an optional "name" parameter, based on the optional 
> status of the parameters I would like to compose string with either the 
> unwrapped value of name, or the string "null". The use case for is syntactic 
> sugar to compose a GraphQL queries.
> 
> A (sampled) illustration of the code that currently solves it looks as 
> following:
> 
> func query(name: String?) {
>   let variables_name = name != nil ? "\"\(name!)\"" : "null"
>   return "{ param: \(variables_name) }"
> }
> 
> Based on optional status the following output is expected
> 
> let name = "Max"
> query(name: name) 
> // { param: "Max" }
> 
> let name: String? = nil
> query(name: name)
> // { param: null }
> 
> I think it might be useful to have an conditional unwrap operator !? that 
> would enable syntax sugar uch as the following built into the language:
> 
> func query(name: String?) {
>   return "{ param: \(name !? "\"\(name)\"": "null") }"
> }
> 
> This expression is expected to produce same output as the examples above. It 
> means check the Optional state of name: String?, in case it has a value, 
> unwrap it and make the unwrapped value accessible under the same name to the 
> true condition part of the expression, otherwise return the false condition 
> part of the expression.
> 
> The effectively removes the need to have the "if != nil" and the forced 
> unwrap syntactical code, and IMHO improves code readability and 
> expressiveness.
> 
> I'm wondering what the community thinks of the displayed use case, and 
> proposed solution?
> 
> 
> -m
> _______________________________________________
> 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

Reply via email to