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
([email protected]) 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 <[email protected]> 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
<[email protected]> 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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
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
