<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">`map`, `filter`, and `reduce` are *the* higher-order functions. Almost anything with any kind of block/lambda/closure feature supports them (I'm giving the side-eye to Foundation here), and all three names are backed by *very* strong conventions</span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">If `map`, `filter`, and `reduce` are not covered by the term-of-art rule, we might as well rename it to the sin()-and-Int rule, because I don't know what else it would cover. There is remarkable consistency in the naming of these operations across dozens of languages.</span></blockquote><div><br></div><div>The point the proposal raises is that the modified versions preserve the the terms of art in all the senses that matter (i.e. all the benefits like recognition etc. still apply).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 17, 2016 at 2:12 PM, Vladimir.S <span dir="ltr"><<a href="mailto:svabox@gmail.com" target="_blank">svabox@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 17.06.2016 8:02, Patrick Pijnappel via swift-evolution wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
-1, for the same reasons stated on the thread. These are neither<br>
guaranteed to be mutating or non-mutating until you get to Collection.<br>
Changing map() to mapped() would be lying to the developer some of the<br>
time about the mutability of the interface.<br>
-DW<br>
<br>
<br></span>
Actually the -ed/-ing suffix is *not *intended to guarantee<span class=""><br>
non-mutatability. It merely communicates whether it is a<br>
"return-a-transformed-version-of-the-instance"-type method as opposed to an<br>
in-place mutation. Clearly these are not in-place forms. Note that this is<br>
my interpretation of the intent of the guidelines (or what should be the<br>
intent) – if the core team agrees perhaps this deserves clarification in<br>
the document.<br>
</span></blockquote>
<br>
Totally agree with you. I also understand this rule as separation of "in-place"/"returns transformed version". I.e. the suffix should say just "result of this operation will be returned and should be assigned to other instance variable". Otherwise, as I understand, ANY method that will touch or iterate the Sequence *could* mutate it and so potentially we should have no -ing/-ed methods for Sequence - no?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
These functions are different than for example `sort` because there<br>
can’t be a general mutating method of `map`. A variable of type `[A]`<br>
can’t be mutated to hold a `[B]` which would be the result of a map<br>
from `A -> B`.<br>
<br>
<br></span>
There could definitely be an in-place variant of filter. While a /fully/<span class=""><br>
general method would not be possible for the others, an user might<br>
reasonable expect in-place variants of map/flatMap if T == U as with e.g. {<br>
$0 * 2 } or Optionals, and of dropFirst/dropLast if SubSequence == Sequence<br>
as with e.g. String.<br>
<br>
Also note that the -ed/-ing rule should not be merely for ambiguous cases,<br>
it should tell the user that the main use of the method is returning a<br>
transformed version of the instance. Having this be a rule you can depend<br>
on is important.<br>
</span></blockquote>
<br>
+1<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
-1 The Term of Art argument is very strong with these functions. I<br>
prefer them as-is.<br>
<br>
<br></span>
What specific benefits do we obtain from using the /exact /terms of art vs.<span class=""><br>
the very slightly modified versions proposed?<br>
</span></blockquote>
<br>
Although I believe we can leave map&reduce as-is, I can understand if we'll change them to mapped/reduced and will have consistent naming everywhere, don't think this will cause any confusion for one who will start to use them. In any case, we can add a hint in compiler like "did you mean 'mapped'?".<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
On Fri, Jun 17, 2016 at 3:24 AM, Brent Royal-Gordon via swift-evolution<br></span><span class="">
<<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>>> wrote:<br>
<br>
> The 'reduce()' at its core take an array of element and reduce it to single element (could be of a different type) as such it cannot ever be mutating (if one really want it, one could reduce an array to the same array but it is not the goal of the function). For this one it sound to me nearly like asking to rename 'max()' to 'maxed()', 'count' to 'counted' or implement a 'summed()' instead of a 'sum()' for [Int].<br>
<br>
`max`, `count`, and `sum` are all nouns—at least in the senses they are<br>
meant in those calls—so they do not take the -ed/-ing suffixes to form<br>
immutable variants. Instead, they would take the `form` prefix to form<br>
mutable variants, if they had them.<br>
<br>
`map`, `filter`, and `reduce`—at least in the senses they must be<br>
interpreted in for the names of those calls to make sense—are verbs,<br>
and so they *would* normally take -ed/-ing suffixes. However, as<br>
broadly-accepted terms of art, we have left them alone until now.<br>
<br>
--<br>
Brent Royal-Gordon<br>
Architechies<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br></span>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank">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><span class=""><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">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>
<br>
</span></blockquote>
</blockquote></div><br></div>