[swift-evolution] Optional Argument Chaining
Benjamin Spratling
bspratling at mac.com
Tue Dec 12 13:42:13 CST 2017
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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/e68684a0/attachment.html>
More information about the swift-evolution
mailing list