<html><head><style>
body {
font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
padding:1em;
margin:auto;
background:#fefefe;
}
h1, h2, h3, h4, h5, h6 {
font-weight: bold;
}
h1 {
color: #000000;
font-size: 28pt;
}
h2 {
border-bottom: 1px solid #CCCCCC;
color: #000000;
font-size: 24px;
}
h3 {
font-size: 18px;
}
h4 {
font-size: 16px;
}
h5 {
font-size: 14px;
}
h6 {
color: #777777;
background-color: inherit;
font-size: 14px;
}
hr {
height: 0.2em;
border: 0;
color: #CCCCCC;
background-color: #CCCCCC;
display: inherit;
}
p, blockquote, ul, ol, dl, li, table, pre {
margin: 15px 0;
}
a, a:visited {
color: #4183C4;
background-color: inherit;
text-decoration: none;
}
#message {
border-radius: 6px;
border: 1px solid #ccc;
display:block;
width:100%;
height:60px;
margin:6px 0px;
}
button, #ws {
font-size: 12 pt;
padding: 4px 6px;
border-radius: 5px;
border: 1px solid #bbb;
background-color: #eee;
}
code, pre, #ws, #message {
font-family: Monaco;
font-size: 10pt;
border-radius: 3px;
background-color: #F8F8F8;
color: inherit;
}
code {
border: 1px solid #EAEAEA;
margin: 0 2px;
padding: 0 5px;
}
pre {
border: 1px solid #CCCCCC;
overflow: auto;
padding: 4px 8px;
}
pre > code {
border: 0;
margin: 0;
padding: 0;
}
#ws { background-color: #f8f8f8; }
.bloop_markdown table {
border-collapse: collapse;
font-family: Helvetica, arial, freesans, clean, sans-serif;
color: rgb(51, 51, 51);
font-size: 15px; line-height: 25px;
padding: 0; }
.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }
.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }
.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }
.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }
.bloop_markdown blockquote{
border-left: 4px solid #dddddd;
padding: 0 15px;
color: #777777; }
blockquote > :first-child {
margin-top: 0; }
blockquote > :last-child {
margin-bottom: 0; }
code, pre, #ws, #message {
word-break: normal;
word-wrap: normal;
}
hr {
display: inherit;
}
.bloop_markdown :first-child {
-webkit-margin-before: 0;
}
code, pre, #ws, #message {
font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}
.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><p>This is an interesting example but I think the solution might be simple if we try to desugar it.</p>
<pre><code class="swift">// 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
}
</code></pre>
<p>Final syntax aside, let’s use the optional function syntax from obj-c world here for a moment: <code>f?(g(), h(), i(), j(), k())</code> where the function signature would look like <code>func f(_: G, _: H, _: I, _: J, _: K?)</code>.</p>
<p>Only if the parameter type is non-optional and the argument is optional then we can desugar it like this:</p>
<pre><code class="swift">let/var someF: SomeType?
if let someG = g(), let someH = h(), let someJ = j() {
someF = f(someG, someH, i(), someJ, k())
} else {
someF = nil
}
</code></pre>
<p>No need to unwrap the result from <code>k()</code> here.</p>
<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1513027435575704064" class="bloop_sign"></div> <br><p class="airmail_on">Am 11. Dezember 2017 um 20:28:52, Xiaodi Wu via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>
<title></title>
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.<br>
<br>
One major challenge to this idea, for which no satisfactory answer
has been achieved after all these years, is the following
issue:<br>
<br>
f(g()?, h()?, i(), j()?)?<br>
<br>
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?<br>
<br>
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.<br>
<div class="gmail_quote">
<div dir="ltr">On Mon, Dec 11, 2017 at 12:34 Magnus Ahltorp via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> 12 Dec. 2017 02:58 Jared Khan <<a href="mailto:jaredkhan@me.com" target="_blank">jaredkhan@me.com</a>>
wrote:<br>
><br>
> 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.<br>
<br>
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.<br>
<br>
> 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.<br>
<br>
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.<br>
<br>
> 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?<br>
<br>
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.<br>
<br>
/Magnus<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote>
</div>
_______________________________________________<br>swift-evolution mailing list<br>swift-evolution@swift.org<br>https://lists.swift.org/mailman/listinfo/swift-evolution<br></div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>