[swift-evolution] Brainstorming: New operator type - chaining

Austin Zheng austinzheng at gmail.com
Sun Jan 31 19:23:10 CST 2016


I think HKTs would be required to allow a generic implementation to serve all monadic instances, but even today there's no way AFAIK to replicate the "?." style chaining operator for any type of arguments in user code.

I would be +1 for the original proposal. Just as we have "if let actualThing = thing" syntax for the common case of optional unwrapping, and "if case let .Foo(x) = y" syntax that is more generally applicable, it would be great to have "?." used to chain optionals and a similar syntax allowing for other types (like a Result<T, ErrorType> or a Promise) to be chained. The chaining method calls on optionals make using them a lot less onerous than if only (e.g.) nested explicit if-let unwrapping were available.
 
Best,
Austin

> On Jan 31, 2016, at 5:14 PM, Tyler Cloutier via swift-evolution <swift-evolution at swift.org> wrote:
> 
> And by Applicative Functor, I believe I actually intend Monad.
> 
> Tyler
> 
> 
>> On Jan 31, 2016, at 5:07 PM, Tyler Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>> On Jan 30, 2016, at 9:20 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> On Jan 30, 2016, at 3:06 PM, Joseph Lord via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> Use case 2 - Chaining on custom types
>>>> 
>>>> And this especially may not be feasible and I may be out of my depth describing the requirement but it feels like a more general case so at least worth airing):
>>> 
>>> I’m not certain I understand the problem you’re looking to solve here, but I think it would be great (though probably very low priority) to open up the functionality of the postfix optional chaining operator to other types.  This could allow its monadic binding (aka railroad short circuiting) behavior to be extended to other types like Result, a left-biased-either, or an arbitrary type defined by the user.  A natural approach would be to capture this behavior in an “chainable” protocol of some sort.
>>> 
>>> This is low priority because I don’t know a lot of killer applications of it, I’m motivated by my ivory tower desire to push compiler magic into the standard library.  It bugs me that optional has sugar and other behavior that other types can’t participate in.
>> 
>> I’m admittedly a novice in functional programming, but couldn’t this be accomplished with Higher Kinded Types? Forgive me if I misunderstand, but it strikes me that Optional Chaining raises the chained operation into the optional context, such that “failed" operations propagate the current .None optional context. Isn’t the purpose of Applicative Functors to define this type of behavior for all such types that have this property?
>> 
>> Tyler
>> 
>> _______________________________________________
>> 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/20160131/831cc62e/attachment.html>


More information about the swift-evolution mailing list