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

Tyler Cloutier cloutiertyler at aol.com
Sun Jan 31 19:07:14 CST 2016

> On Jan 30, 2016, at 9:20 PM, Chris Lattner via swift-evolution <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?


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

More information about the swift-evolution mailing list