<div dir="ltr">Hello all,<div><br></div><div>Firstly, I would like to "throw my hat in the ring" in support of Optional.ifPresent().</div><div><br></div><div>I have come across many opportunities to use such a utility function and have used begun using a similar function in Java 8's Optional object very frequently.</div><div><br></div><div>If others feel similarly, I would happily support or issue a proposal for that single addition:</div><div><br></div><div>```</div><div>public enum Optional<Wrapped>: ... {</div><div> ...<br> /// If `self == nil` the function call is a no-op. Otherwise, calls body(self!).<br> public func ifPresent(@noescape body: (Wrapped) throws -> Void) rethrows -> Void {<div> switch self {</div><div> case .None: return</div><div> case .Some(let wrapped): try body(wrapped)</div><div> }<br> }</div><div> ...</div>}<br>```</div><div><br></div><div>However, in regard to expanding Optional's implementation from a simple enum with an associated value to a CollectionType, I feel that this may be a bit of a distraction and could fall into a category of "premature optimization."<br></div><div><br></div><div>I would argue that attempting to simplify the implementation semantics should be considered a secondary goal to keeping the end-user (swift developer) semantics easy to use and understand. The addition of an abstract "boxed type" to organize methods that share names and conceptual actions but different implementations may not be absolutely immediately necessary or helpful.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 14, 2016 at 1:18 PM, Daniel Vollmer via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
> On 13 Mar 2016, at 18:04, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
> I am in favour of making optionals consistently act like 1-item-max collections.<br>
<br>
Why stop there? Why not make all non-optionals collections of one?<br>
<br>
I’m not convinced that making optionals conform to CollectionType actually improves matters: Yes, it may make the odd use here or there slightly more convenient, but at the cost of clarity IMO: Optionals have largely different set of concerns than collections, and having them suddenly inherit all CollectionType functionality and extensions doesn’t make their use (if it relies on them) any clearer, it obscures their “Optional”-ness instead.<br>
<br>
Daniel.<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">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></div>