<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 25, 2016 at 1:11 PM, Dave Abrahams 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span><br>
</span>I'm giving the overall idea a +0 and the specific proposal as currently<br>
written a -1, because I think this is a much more complicated bikeshed<br>
than it appears to be on the surface and the proposal doesn't begin to<br>
address the issues. Specifically, I'm concerned about these points:<br>
<br>
* `flatten` works on Optional<Optional<T>> and sequences of Optional<T>.<br>
How does it make sense to rename these operations “join?”<br></blockquote><div><br></div><div>Does it really? These don't work for me:</div><div><br></div><div>let x = [1,2,nil,4]</div><div>x.flatten()</div><div><br></div><div>let y = Optional(Optional(42))</div><div>y.flatten() </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* The name and semantics of `flatten` is linked to that of `flatMap`.<br>
It's almost impossible to explain what `flatMap` does without<br>
reference to `flatten`. Will it make sense to explain `flatMap` in<br>
terms of `joined`?<br></blockquote><div><br></div><div>I think the current documentation comments do a pretty good job:</div><div><br></div><div>On the [T].flatMap(T -> U?) -> [U] version:</div><div><div><div> /// Returns an array containing the non-`nil` results of calling the given</div><div> /// transformation with each element of this sequence.</div></div></div><div><br></div><div>On the [T].flatMap(T -> [U]) -> [U] version:<br></div><div><div><div> /// Returns an array containing the concatenated results of calling the</div><div> /// given transformation with each element of this sequence.</div></div></div><div><br></div><div>(This one also mentions array.map(transform).flatten(), which would become array.map(transform).joined().)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* `flatten` is a functional term of art in the same family as `flatMap`.<br>
We have good reasons to consider changing some of the other names in<br>
this family, such as `filter` and `reduce`, but that idea has met with<br>
significant resistance on the list. How far should we go? Does it<br>
make sense to make this one change alone?<br></blockquote><div><br></div><div>I wouldn't argue for renaming flatMap. I'm not suggesting to change the name of flatten() because I don't like it (I do); I'm suggesting to change it because — unlike Ruby, whose Array has #flatten and #join, but the latter is *only* for producing strings — we seem to have the *same* functionality behind 2 differently-named APIs.</div><div><br></div><div>(Actually I feel like flatMap is a more fundamental functional method in the family of filter and reduce than flatten/joined is. flatten is just flatMap({$0}), although as pointed out above, flatten isn't actually available in all the places that flatMap({$0}) would work.)</div><div><br></div><div>Jacob</div></div><br></div></div>