[swift-evolution] Optional Argument Chaining

Tue Dec 12 14:00:36 CST 2017

That’s actually the cool part of merging optional func infix ? with the discussed problem. If you think how we could represent optional func in pure swift only with some sugar (and also the ability to write var function(label:label:) which we’ll get at some point) then we could do this:

protocol P {
    optional func foo(label: Int)
}

// compiler could synthesize this for you:
extension P {
    default var foo(label:): ((Int) -> Void)? { return nil }
}

(someInstance as P).foo?(label: 42)
default is from https://github.com/erica/swift-evolution/blob/a260a33ca39676b41e0436c4dccdb78441308c13/proposals/XXXX-role-keywords.md

Now back to your example, the answer becomes really easy:

let c = someFunction?(a, b)

This can then be desugared to:

let c = {
    if let someFunction = someFunction, let someA = a, let someB = b {
        return someFunction(someA, someB)
    } else {
        return nil
    }
}
In any case c would be Optional<Int>.

Am 12. Dezember 2017 um 20:42:20, Benjamin Spratling (bspratling at mac.com) schrieb:

In addition to being unspecific, how would you access an optional closure?  Since trailing operators can’t be separated with whitespace, how do you differentiate two trailing “?” from a “??” operator?

i.e. 

let a:Int? = ...
let b:Int? = ...
let someFunction:((Int, Int)->(Int))? = ...
let c = someFunction??(a, b)

It seems like it’s trying to provide a fallback of (Int?, Int?) instead of Int?.
I’m on the side of using the postfix “?” on the specific optional values, not on the function name.  It has the benefit of not being confusing to someone new approaching the language because they are adjacent to the thing to change instead of in some other location.

In response to other criticisms, it seems very odd to me that the question of evaluation order of arguments is a serious problem for the original idea.

On Dec 12, 2017, at 2:32 PM, Adrian Zubarev via swift-evolution <swift-evolution at swift.org> wrote:

I propose that we do not add a suffix ? to the arguments because it does not really signal that the whole function may return an optional value. This is especially not convenient in a nested scenario like mentioned by others in previous posts. Instead we should reuse the inifix ? on functions, subscripts and initializer. This way we can signal that the function might fail if one of the provided optional arguments could not be unwrapped where the function expects a non-optional argument. If the return type was already an optional, we do not generate a nested optional, because there is no real reason for us to do so. All arguments can simply be passed to the function with an infix ? in their current form. If all non-optional parameter types match with the argument types - optional parameter types can safely be ignored - we generate an error, thus we don’t need an infix ?, otherwise the conversion happens implicitly. This approach removes the need for explicit argument annotations, which is IMHO boilerplate in first place. It also provides a hint to the reader that some of the passed arguments should be unwrapped to succeed. In every chase the ? is always close to the parameter list ?(_:_:...).

Here are some simple examples to consider: 

func first(one: A, two: B, three: C?) -> D { ... }
func second(one: A, two: B, three: C?) -> D? { ... }
————————————————————————————————————————————————

// error when adding infix `?` if all arguments match the types
first?(one: a, two: b, three: c) // c can be both optional and non-optional
————————————————————————————————————————————————

// no need for infix `?`
first(one: a, two: b, three: optionalC) // returns `D`   
————————————————————————————————————————————————

// sugared
first?(one: optionalA, two: b, three: c) // returns `D?` if succeed

// desugared
{ () -> D? in
    if let someA = optionalA {
        return first(one: someA, two: b, three: c)
    } else {
        return nil
    }
}()
————————————————————————————————————————————————

// sugared
first?(one: optionalA, two: optionalB, three: optionalC) // returns `D?` if succeed

// desugared
{ () -> D? in
    if let someA = optionalA, let someB = optionalB {
        return first(one: someA, two: someB, three: optionalC)
    } else {
    return nil
    }     
}()
————————————————————————————————————————————————

// error when adding infix `?` if all arguments match the types
second?(one: a, two: b, three: c) // c can be both optional and non-optional
————————————————————————————————————————————————

// no need for infix `?`
second(one: a, two: b, three: optionalC) // returns `D?`   
————————————————————————————————————————————————

// sugared
second?(one: optionalA, two: b, three: c) // returns `D?` if succeed - no need for nested optionals!

// desugared
{ () -> D? in
    if let someA = optionalA {
        return second(one: someA, two: b, three: c)
    } else {
        return nil
    }
}()
————————————————————————————————————————————————

// sugared
second?(one: optionalA, two: optionalB, three: optionalC) // returns `D?` if succeed - no need for nested optionals!

// desugared
{ () -> D? in
    if let someA = optionalA, let someB = optionalB {
        return second(one: someA, two: someB, three: optionalC)
    } else {
        return nil
    }
}()
Please note that this can only work with non-operator functions and initializers. Operator functions cannot be referenced as normal functions yet and optional subscripts would require a source breaking change to align with that behaviour.

If I missed something where optional func from Objective-C results into incompatibility with this approach, please fell free to correct me. From my point of view I don’t see how this additional behaviour could break optional func.

Am 12. Dezember 2017 um 19:47:25, Jared Khan via swift-evolution (swift-evolution at swift.org) schrieb:

Even this small example I think this is still a little fiddly. If we add another required parameter to the Markdown initializer:
let readme = String(contentsOfFile: “README.md”).flatMap { Markdown(string: $0, flavor: .github) }
this starts to feel a little inside-out and crufty to me. 

On 12 Dec 2017, at 05:54, Félix Cloutier <felixcloutier at icloud.com> wrote:

You talk about flatMap without giving an example. The readme isn't that bad with it, IMO:

if let readme = String(contentsOfFile: "README.md").flatMap(Markdown) {
// use contents here
}

That doesn't work when you need multiple optional parameters. In my own experience, that hasn't been a huge problem, though.

Félix

Le 11 déc. 2017 à 08:30, Jared Khan via swift-evolution <swift-evolution at swift.org> a écrit :

Hi all,

I'd like to propose a syntax addition that acts to ease some things that I believe should fall under the umbrella of 'optional chaining'. Optional chaining allows us to access the properties of an optional value and return nil if any link in that chain breaks. I propose we introduce syntax to allow similar chaining when passing optional valued parameters to functions that expect that parameter to be non-optional.

The example below is taken from a project I'm working on at the moment:

// Current
let readme: Markdown?
if let rawMarkdown = String(contentsOfFile: "README.md") {
        readme = Markdown(string: rawMarkdown)
} else {
        readme = nil
}
In this example we want to perform an operation, the initialisation of a 'Markdown' type, with our raw text if it exists and get nil otherwise. This is rather verbose

I propose the following syntax for an alternative:

// Proposed alternative
let readme = Markdown(string: String(contentsOfFile: "README.md")?)

The ? is familiar in its use for optional chaining.

This would act like syntactic sugar for the flatMap method on Optional. For example:

(where `john` is of a `Person` type with a property `address: Address?`)
// func getZipCode(fromAddress address: Address) -> ZipCode
getZipCode(fromAddress: john.address?)

// Would be equivalent to…
john.address.flatMap {
        getZipCode($0)
}
An example with multiple parameters:

// func getPostageEstimate(source: Address, destination: Address, weight: Double) -> Int
getPostageEstimate(source: john.address?, destination: alice.address?, weight: 2.0)

// Equivalent to
john.address.flatMap { freshVar1 in
        alice.address.flatMap { freshVar2 in
                getPostageEstimate(source: freshVar1, destination: freshVar2, weight: 2.0)
        }
}

// Or equally:
{
        guard let freshVar1 = john.address,
                let freshVar2 = alice.address else {
                        return nil
        }

        return getPostageEstimate(source: freshVar1, destination: freshVar2, weight: 2.0)
}()
This would only be allowed when the parameter doesn’t already accept Optionals and when the chained value is in fact an optional. We’d want to consider emitting at least the following errors/warnings in the given scenarios:

let result = myFunc(3?)
// error: cannot use optional chaining on non-optional value of type 'Int'

// func myFunc2(x: String?) -> String
let result = myFunc2(x: john.address?)
// error: cannot use optional argument chaining on argument of optional type
let result = myFunc(nil?)
// warning: optional argument chaining with nil literal always results in nil

Seeking your thoughts on this idea, the specific syntax, and more use case examples.

Best,

Jared

_______________________________________________
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

_______________________________________________
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/20171212/8216a298/attachment.html>