This is an interesting example but I think the solution might be simple if we
try to desugar it.
// example
f(g()?, h()?, i(), j()?)?
// desugared
let/var someF: SomeType?
if let someG = g(), let someH = h(), let someJ = j() {
someF = f(someG, someH, i(), someJ)
} else {
someF = nil
}
Final syntax aside, let’s use the optional function syntax from obj-c world
here for a moment: f?(g(), h(), i(), j(), k()) where the function signature
would look like func f(_: G, _: H, _: I, _: J, _: K?).
Only if the parameter type is non-optional and the argument is optional then we
can desugar it like this:
let/var someF: SomeType?
if let someG = g(), let someH = h(), let someJ = j() {
someF = f(someG, someH, i(), someJ, k())
} else {
someF = nil
}
No need to unwrap the result from k() here.
Am 11. Dezember 2017 um 20:28:52, Xiaodi Wu via swift-evolution
(swift-evolution@swift.org) schrieb:
This topic has been discussed at least two and maybe more times in the past.
It’s hard for me to post links at the moment, but it should be possible to find
on Google.
One major challenge to this idea, for which no satisfactory answer has been
achieved after all these years, is the following issue:
f(g()?, h()?, i(), j()?)?
If g() evaluates to nil, is h() called or not? How about i(), which is not
failable? Since any function or property access can have side effects, in what
order are the arguments evaluated, and how does one reason about this code flow?
To my mind, in the absence of an intuitive answer to the above—which does not
appear to be possible—this idea is not feasible.
On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via swift-evolution
<swift-evolution@swift.org> wrote:
> 12 Dec. 2017 02:58 Jared Khan <jaredk...@me.com> wrote:
>
> 2. It felt natural to me. It’s analogous to the existing optional chaining
> scenarios and composes nicely. I think it’s about as understandable as
> existing chaining, a newbie would have to look it up to discover its meaning.
> What are your thoughts on this particular syntax (ignoring 3. momentarily)?
> Hopefully others in this thread can share their views too.
Chaining methods is linear, while nesting fills a similar purpose when we use
function calls. This of course affects the way existing Swift code is written,
but that is something we have to live with if we want to use familiar syntax
patterns. However, I think we have to consider this difference in this case,
since the syntax becomes more convoluted. Your suggestion is definitely not as
easy to read as the optional chaining syntax, and maybe it can't be.
> As for how common I’d expect it to be, it’s something I’ve run into myself a
> few times. Again, I hope members of this list can give their view on if this
> would be useful to them.
I don't have any real examples, but I certainly think that I have run into it,
so I'm quite open to solving the problem. For me, it is probably only a matter
of finding a syntax that is acceptable.
> 3. I’m not entirely sure what the grammar situation is yet but afaik ‘?’ has
> never been available as a postfix operator. Perhaps I’m missing your point,
> could you demonstrate where it is allowed?
I did not expect that you would be able to answer that, it was more a question
directed to people who are more connected to the inner workings of the parsing
of Swift than I am. It is not allowed, but the error message is not the one I
expect, something that gives me a hint that it does have some meaning early in
the parsing.
/Magnus
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
