[swift-evolution] Optional Argument Chaining

Charles Augustine hyllus04 at gmail.com
Mon Dec 11 11:56:43 CST 2017


I don’t think that solves the same thing.  The problem is I read it is to allow some sort of short hand to be able to pass optional types as parameters into methods / initializers that do not take optional types.  The result of that method / initializer being nil if any of said parameters were nil or a typical result otherwise.  Based on your example I think it’s identical to the existing ?? operator, is it not?

As per the suggested syntax, I do think that we would want to be able to control this feature on a per parameter basis, so it would make sense to have the ? operator placed after the parameter that needed to be unwrapped.  This would also be more consistent with the usage of the existing syntax.

— Charles

> On Dec 11, 2017, at 9:37 AM, C. Keith Ray via swift-evolution <swift-evolution at swift.org> wrote:
> 
> You can create a binary operator that tests the left-hand operand for nil, and passes the unwrapped value to the right-hand operand (a function taking one value), this operator can be made left-associative to allow chaining.
> 
> let m = String(contentsOfFile: "README.md") ??? Markdown 
> where ??? is the operator described above.
> 
> --
> C. Keith Ray
> 
> * https://leanpub.com/wepntk <https://leanpub.com/wepntk> <- buy my book?
> * http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf <http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf>
> * http://agilesolutionspace.blogspot.com/ <http://agilesolutionspace.blogspot.com/>
> 
> On Dec 11, 2017, at 9:07 AM, Magnus Ahltorp via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> 
>>> 12 Dec. 2017 01:30 Jared Khan via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 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.
>> 
>> 1. Am I right in assuming that you propose that the suffix operator "?" would make the result of the surrounding method/function call optional, so that a(b(c?)) would make the result of the "b" function call optional, but not the "a" function call, and that it would be a(b(c?)?) if we would like to propagate this two levels?
>> 
>> 2. If that is the case, is that understandable/neat enough? How common would you expect this to be?
>> 
>> 3. For some reason, (in current Swift) the suffix operator "?" seems to be allowed in intra-expression syntax, and only fails when the inter-expression syntax is checked for optionality congruence. Is there a reason for this? I would have expected that the congruence error "cannot use optional chaining on non-optional value of type" would never be seen for a lone "?", since the error message "'?' must be followed by a call, member lookup, or subscript" would always be displayed first if it was checked first. The "." operator checks intra-expression syntax first, before checking congruence. Is this a sign that "?" as a suffix operator is already somewhat operational as an operator for optional types? I have a faint recollection that it was doing something in earlier versions of Swift.
>> 
>> /Magnus
>> 
>> _______________________________________________
>> 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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171211/76f539a8/attachment.html>


More information about the swift-evolution mailing list