[SR-933] Rename flatten to flattened

Hey guys,

The 'flatten()' method didn't get the Swift 3 API renaming treatment it
should have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to discuss
it here. So what do you think?

Implementation: [SR-933] rename flatten to flattened by frootloops · Pull Request #2038 · apple/swift · GitHub

Cheers,
Arsen

I agree. The related types (currently FlattenCollection, FlattenSequence) should get renamed as well.

Cheers,
Guillaume Lessard

I am agnostic on this, but should explain the rationale for the current
name. It wasn't overlooked. We kept flatten as is because it is part of
a suite of methods that are terms of art from functional programming
(map, filter, flatMap, reduce) that don't follow the naming guidelines
but we are nonetheless leaving alone. The fact that the semantics of
flatMap can only be sensibly described in terms of map and flatten
reinforces this rationale.

If we want to change flatten, we should decide whether this is a
principled change, and if so, what the principle is. If it's a change
simply because “flatten() feels weird,” that's OK too, but we should
understand what we're doing and why.

···

on Thu Apr 07 2016, Arsen Gasparyan <swift-evolution@swift.org> wrote:

Hey guys,

The 'flatten()' method didn't get the Swift 3 API renaming treatment it should
have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to discuss it
here. So what do you think?

Implementation: [SR-933] rename flatten to flattened by frootloops · Pull Request #2038 · apple/swift · GitHub

--
Dave

In the sense that these are existing terms of art from functional programming, they inherit the meaning of being non-mutating.

If we did consider changing the name of one, I’d prefer if we considered all of them at once (so the various bike sheds would be painted in complementary colors)

-DW

···

On Apr 7, 2016, at 12:12 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

on Thu Apr 07 2016, Arsen Gasparyan <swift-evolution@swift.org> wrote:

Hey guys,

The 'flatten()' method didn't get the Swift 3 API renaming treatment it should
have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to discuss it
here. So what do you think?

Implementation: [SR-933] rename flatten to flattened by frootloops · Pull Request #2038 · apple/swift · GitHub

I am agnostic on this, but should explain the rationale for the current
name. It wasn't overlooked. We kept flatten as is because it is part of
a suite of methods that are terms of art from functional programming
(map, filter, flatMap, reduce) that don't follow the naming guidelines
but we are nonetheless leaving alone. The fact that the semantics of
flatMap can only be sensibly described in terms of map and flatten
reinforces this rationale.

If we want to change flatten, we should decide whether this is a
principled change, and if so, what the principle is. If it's a change
simply because “flatten() feels weird,” that's OK too, but we should
understand what we're doing and why.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I think it makes sense to just rename them; it’s not as though flattened or mapped is somehow far removed from the original meaning as the actual action is the same, it’s just changing tense.

For users coming to Swift as a first language I think that consistent naming is more important, and while terms of art are useful, it’s not as if changing the tense is changing the meaning or making them hard to find; anyone that types myArray.map… will have Xcode present them with .mapped. If we want mutating forms of this methods then I much prefer .map() and .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts the naming convention used everywhere else which only adds confusion.

Besides, I’d say the terms of art in these cases are more about what the basic operation does, whether or not the method manipulates the original is something that a developer should really check, i.e- when I look for .map in a new language I’m looking for a transformation method, I’ll then check what exactly that transformation does to the original collection. Plus features like unused result and type checks should keep people right about wether they’re using it correctly, so any mistake should be caught pretty easily.

···

On 7 Apr 2016, at 19:12, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:

We kept flatten as is because it is part of a suite of methods that are terms of art from functional programming (map, filter, flatMap, reduce) that don't follow the naming guidelines

1 Like

The 'flatten()' method didn't get the Swift 3 API renaming treatment it should have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to discuss it here. So what do you think?

I'm in favor.

Though all of these things are terms of art, not all terms of art are created equal. For instance:

* `map` is supported by virtually any language which have any of these higher-order functions, and to my knowledge the name `map` is universally used.
* `reduce` is not quite as universally supported, but it's still very common, and most (but not quite all) languages with higher-order functions support it.
* `filter` is very widely supported, but the *name* `filter` is not quite so consistent. Ruby, for instance, calls it `select`, Perl calls it `grep`, etc.
* `takeWhile` lies on the other end of the spectrum, being very narrowly supported.

In my opinion, it would be a really bad idea to rename `map` or `reduce`; `filter` is probably a bad idea but not terrible; but we should feel relatively free to rename `takeWhile`.

`flatten` is nowhere near as weak a term of art as `takeWhile`, but I think it still falls towards that end of the spectrum. We shouldn't worry too much about changing it. `map`, `reduce`, and `filter` are much stronger terms, and we should be more cautious about changing them.

···

--
Brent Royal-Gordon
Architechies

I would prefer to change them all: mapped, filtered, flatMapped, reduced,
and flattened.

···

On Friday, 8 April 2016, David Waite via swift-evolution < swift-evolution@swift.org> wrote:

In the sense that these are existing terms of art from functional
programming, they inherit the meaning of being non-mutating.

If we did consider changing the name of one, I’d prefer if we considered
all of them at once (so the various bike sheds would be painted in
complementary colors)

-DW

> On Apr 7, 2016, at 12:12 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org <javascript:;>> wrote:
>
>
> on Thu Apr 07 2016, Arsen Gasparyan <swift-evolution@swift.org > <javascript:;>> wrote:
>
>> Hey guys,
>>
>> The 'flatten()' method didn't get the Swift 3 API renaming treatment it
should
>> have, to go along with reversed, sorted, joined, etc.
>> As I see Dmitri Gribenko already agree with it but we still have to
discuss it
>> here. So what do you think?
>>
>> Implementation: [SR-933] rename flatten to flattened by frootloops · Pull Request #2038 · apple/swift · GitHub
>
> I am agnostic on this, but should explain the rationale for the current
> name. It wasn't overlooked. We kept flatten as is because it is part of
> a suite of methods that are terms of art from functional programming
> (map, filter, flatMap, reduce) that don't follow the naming guidelines
> but we are nonetheless leaving alone. The fact that the semantics of
> flatMap can only be sensibly described in terms of map and flatten
> reinforces this rationale.
>
> If we want to change flatten, we should decide whether this is a
> principled change, and if so, what the principle is. If it's a change
> simply because “flatten() feels weird,” that's OK too, but we should
> understand what we're doing and why.
>
> --
> Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <javascript:;>
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

1 Like

Strong -1 to recycling the meaning of 'map' or any of the others to be the mutating versions. That would make 'map' fundamentally different and even counter to the term of art

-DW

···

On Apr 8, 2016, at 4:19 AM, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

If we want mutating forms of this methods then I much prefer .map() and .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts the naming convention used everywhere else which only adds confusion.

I think it makes sense to just rename them; it’s not as though flattened or mapped is somehow far removed from the original meaning as the actual action is the same, it’s just changing tense.

-1, and not only for the reasons we neither call trigonometric functions `sine`, `cosine`, and `tangent`. The existing names are widely known, commonly taught in modern introductory programming courses, to the point, and googleable.

In addition:

If we want mutating forms of this methods then I much prefer .map() and .mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts the naming convention used everywhere else which only adds confusion.

This idea of in-place versions is innocuous but absurd. In general, there's no way mapping `T -> U` over a `[T]` could possibly accommodate the result in the argument of type `[T]`:

    var xs: [Int] = ...
    xs.mapInPlace {String($0)} // ???

And the same goes for `flatMap`, and `Optional` and others. Likewise, `flatten()` couldn't possibly happen in place because the result type has one level of nesting less than the argument.

— Pyry

···

On 08 Apr 2016, at 13:19, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

Thanks Brent -- I completely agree with your assessment.
I was failing to come up with the proper argument for just about the same idea!

Guillaume Lessard

···

On 8 avr. 2016, at 18:32, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

The 'flatten()' method didn't get the Swift 3 API renaming treatment it should have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to discuss it here. So what do you think?

I'm in favor.

Though all of these things are terms of art, not all terms of art are created equal. For instance:

* `map` is supported by virtually any language which have any of these higher-order functions, and to my knowledge the name `map` is universally used.
* `reduce` is not quite as universally supported, but it's still very common, and most (but not quite all) languages with higher-order functions support it.
* `filter` is very widely supported, but the *name* `filter` is not quite so consistent. Ruby, for instance, calls it `select`, Perl calls it `grep`, etc.
* `takeWhile` lies on the other end of the spectrum, being very narrowly supported.

In my opinion, it would be a really bad idea to rename `map` or `reduce`; `filter` is probably a bad idea but not terrible; but we should feel relatively free to rename `takeWhile`.

`flatten` is nowhere near as weak a term of art as `takeWhile`, but I think it still falls towards that end of the spectrum. We shouldn't worry too much about changing it. `map`, `reduce`, and `filter` are much stronger terms, and we should be more cautious about changing them.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I still don’t see what’s being lost here, it’s not like the proposal is to radically rename them, all we’d end up with is .mapped(), .flattened(), .filtered() etc., which any good search engine should still be able to find, and will still come up in auto-completion if you start typing .map, .flatten and so-on. I just don’t see the point of even having naming conventions if we allow outside influences to force exceptions for IMO fairly weak reasons; it amounts to the “because everyone else is doing it” reasoning, but again, it’s not as if someone used to using .map is going to be suddenly lost and confused when presented with .mapped() instead.

···

On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

`flatten` is nowhere near as weak a term of art as `takeWhile`, but I think it still falls towards that end of the spectrum. We shouldn't worry too much about changing it. `map`, `reduce`, and `filter` are much stronger terms, and we should be more cautious about changing them.

The problem is flatMap. The semantics of map, flatMap, and flatten are
inextricably linked. IMO it would be weird to do this to one or two of
these names and not to all of them.

···

on Fri Apr 08 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

The 'flatten()' method didn't get the Swift 3 API renaming treatment
it should have, to go along with reversed, sorted, joined, etc.
As I see Dmitri Gribenko already agree with it but we still have to
discuss it here. So what do you think?

I'm in favor.

Though all of these things are terms of art, not all terms of art are created equal. For instance:

* `map` is supported by virtually any language which have any of these
higher-order functions, and to my knowledge the name `map` is
universally used.
* `reduce` is not quite as universally supported, but it's still very
common, and most (but not quite all) languages with higher-order
functions support it.
* `filter` is very widely supported, but the *name* `filter` is not
quite so consistent. Ruby, for instance, calls it `select`, Perl calls
it `grep`, etc.
* `takeWhile` lies on the other end of the spectrum, being very narrowly supported.

In my opinion, it would be a really bad idea to rename `map` or
`reduce`; `filter` is probably a bad idea but not terrible; but we
should feel relatively free to rename `takeWhile`.

`flatten` is nowhere near as weak a term of art as `takeWhile`, but I
think it still falls towards that end of the spectrum. We shouldn't
worry too much about changing it. `map`, `reduce`, and `filter` are
much stronger terms, and we should be more cautious about changing
them.

--
Dave

    I think it makes sense to just rename them; it’s not as though flattened or
    mapped is somehow far removed from the original meaning as the actual action
    is the same, it’s just changing tense.

-1, and not only for the reasons we neither call trigonometric functions `sine`,
`cosine`, and `tangent`. The existing names are widely known, commonly taught in
modern introductory programming courses, to the point, and googleable.

In addition:

    If we want mutating forms of this methods then I much prefer .map() and .
    mapped() to .map() and .mapInPlace() or whatever, as the latter contradicts
    the naming convention used everywhere else which only adds confusion.

This idea of in-place versions is innocuous but absurd. In general, there's no
way mapping `T -> U` over a `[T]` could possibly accommodate the result in the
argument of type `[T]`:

var xs: [Int] = ...
xs.mapInPlace {String($0)} // ???

No, you'd just give it a more-restricted signature that only accepted
T->T closures.

And the same goes for `flatMap`, and `Optional` and others. Likewise, `flatten()
` couldn't possibly happen in place because the result type has one level of
nesting less than the argument.

C'rect.

···

on Fri Apr 08 2016, Pyry Jahkola <swift-evolution@swift.org> wrote:

    On 08 Apr 2016, at 13:19, Haravikk via swift-evolution > <swift-evolution@swift.org> wrote:

--
Dave

I think it makes sense to just rename them; it’s not as though flattened or mapped is somehow far removed from the original meaning as the actual action is the same, it’s just changing tense.

-1, and not only for the reasons we neither call trigonometric functions `sine`, `cosine`, and `tangent`. The existing names are widely known, commonly taught in modern introductory programming courses, to the point, and googleable.

I’m not sure if sine, cosine etc. are equivalent to the case of map, flatten and so-on? Are they not nouns rather than verbs?
I don’t think googleable should be that important; what’s important is what the method does, i.e- what you want to do, as long as it’s well described it should still be searchable, especially if there is a mutating equivalent that’s named in present tense.

This idea of in-place versions is innocuous but absurd. In general, there's no way mapping `T -> U` over a `[T]` could possibly accommodate the result in the argument of type `[T]`:

    var xs: [Int] = ...
    xs.mapInPlace {String($0)} // ???

And the same goes for `flatMap`, and `Optional` and others. Likewise, `flatten()` couldn't possibly happen in place because the result type has one level of nesting less than the argument.

True enough, didn’t think that through, though mapping where the type remains unchanged would be possible. Not really the point though, I think it should still be named consistently; if you make exceptions then why have guidelines on naming at all?

···

On 8 Apr 2016, at 12:00, Pyry Jahkola <pyry.jahkola@iki.fi> wrote:

On 08 Apr 2016, at 13:19, Haravikk via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

+1 for Haravikk's reasoning, mapped etc. are the best choice.

···

On Saturday, 9 April 2016, Haravikk via swift-evolution < swift-evolution@swift.org> wrote:

> On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org <javascript:;>> wrote:
>
> `flatten` is nowhere near as weak a term of art as `takeWhile`, but I
think it still falls towards that end of the spectrum. We shouldn't worry
too much about changing it. `map`, `reduce`, and `filter` are much stronger
terms, and we should be more cautious about changing them.

I still don’t see what’s being lost here, it’s not like the proposal is to
radically rename them, all we’d end up with is .mapped(), .flattened(),
.filtered() etc., which any good search engine should still be able to
find, and will still come up in auto-completion if you start typing .map,
.flatten and so-on. I just don’t see the point of even having naming
conventions if we allow outside influences to force exceptions for IMO
fairly weak reasons; it amounts to the “because everyone else is doing it”
reasoning, but again, it’s not as if someone used to using .map is going to
be suddenly lost and confused when presented with .mapped() instead.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

I still don’t see what’s being lost here, it’s not like the proposal is to radically rename them, all we’d end up with is .mapped(), .flattened(), .filtered() etc., which any good search engine should still be able to find, and will still come up in auto-completion if you start typing .map, .flatten and so-on. I just don’t see the point of even having naming conventions if we allow outside influences to force exceptions for IMO fairly weak reasons; it amounts to the “because everyone else is doing it” reasoning, but again, it’s not as if someone used to using .map is going to be suddenly lost and confused when presented with .mapped() instead.

As someone who has been using `map` for virtually my entire programming career, across languages as different as Perl, Haskell, Ruby, Objective-C (with my own categories) and now Swift, I would be as surprised by a `map` named `mapped` as I would be by a letter addressed to "Brented".

The naming exception is simple and principled: When other languages have universally adopted a given name, and there's nothing particularly wrong with that name except that it doesn't match Swift conventions, don't fight the trend just to be different, or just to be self-consistent. People would figure out `mapped`, sure, but `map` causes not even a moment of confusion.

Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, and `foo.tangented`? Or maybe `foo.sine`, `foo.cosine`, and `foo.tangent`, with corresponding `foo.formSine`, `foo.formCosine`, and `foo.formTangent` functions?

Remember the first and most important sentence in the API Guidelines: "Clarity at the point of use is your most important goal." If there is a universally-accepted nomenclature for a particular operation, the clearest thing we can do is to adopt it, even if it doesn't match our normal guidelines.

Consistency is a powerful and satisfying goal, but we must be careful not to be seduced by it. "A foolish consistency is the hobgoblin of little minds." When there is a compelling reason to deviate from the guidelines, we should be prepared to do so.*

Consistency in API naming is a means to convey semantics, not an end in itself. We must not let the cart be put before the horse.

(Besides, since they take arguments, we should favor `mapping`, `filtering`, `flatMapping`, etc. Or perhaps even `mappingFlattened` for the last one. Can you see the rabbit hole we're beginning to tumble down?)

* Well, as the people writing the guidelines, we should try to modify the guidelines to write a general rule accommodating the deviation, because any situation we encounter is likely to be encountered by others as well. We've done that in this case by writing the "term of art" rule.

···

--
Brent Royal-Gordon
Architechies

Yet another +1 for Haravikk's suggestion.

Naming conventions are a good thing and mapped, filtered etc. are a perfect fit. I don't see a reason for an exception here.

R+

···

Sent from my iPhone

On 09 Apr 2016, at 11:03, Haravikk via swift-evolution <swift-evolution@swift.org> wrote:

On 9 Apr 2016, at 01:32, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

`flatten` is nowhere near as weak a term of art as `takeWhile`, but I think it still falls towards that end of the spectrum. We shouldn't worry too much about changing it. `map`, `reduce`, and `filter` are much stronger terms, and we should be more cautious about changing them.

I still don’t see what’s being lost here, it’s not like the proposal is to radically rename them, all we’d end up with is .mapped(), .flattened(), .filtered() etc., which any good search engine should still be able to find, and will still come up in auto-completion if you start typing .map, .flatten and so-on. I just don’t see the point of even having naming conventions if we allow outside influences to force exceptions for IMO fairly weak reasons; it amounts to the “because everyone else is doing it” reasoning, but again, it’s not as if someone used to using .map is going to be suddenly lost and confused when presented with .mapped() instead.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Do it to them all: flatMapped, unioned, etc.

···

On Monday, 11 April 2016, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:

on Fri Apr 08 2016, Brent Royal-Gordon <swift-evolution@swift.org > <javascript:;>> wrote:

>> The 'flatten()' method didn't get the Swift 3 API renaming treatment
>> it should have, to go along with reversed, sorted, joined, etc.
>> As I see Dmitri Gribenko already agree with it but we still have to
>> discuss it here. So what do you think?
>
> I'm in favor.
>
> Though all of these things are terms of art, not all terms of art are
created equal. For instance:
>
> * `map` is supported by virtually any language which have any of these
> higher-order functions, and to my knowledge the name `map` is
> universally used.
> * `reduce` is not quite as universally supported, but it's still very
> common, and most (but not quite all) languages with higher-order
> functions support it.
> * `filter` is very widely supported, but the *name* `filter` is not
> quite so consistent. Ruby, for instance, calls it `select`, Perl calls
> it `grep`, etc.
> * `takeWhile` lies on the other end of the spectrum, being very narrowly
supported.
>
> In my opinion, it would be a really bad idea to rename `map` or
> `reduce`; `filter` is probably a bad idea but not terrible; but we
> should feel relatively free to rename `takeWhile`.
>
> `flatten` is nowhere near as weak a term of art as `takeWhile`, but I
> think it still falls towards that end of the spectrum. We shouldn't
> worry too much about changing it. `map`, `reduce`, and `filter` are
> much stronger terms, and we should be more cautious about changing
> them.

The problem is flatMap. The semantics of map, flatMap, and flatten are
inextricably linked. IMO it would be weird to do this to one or two of
these names and not to all of them.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <javascript:;>
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.

Ok. Is it final decision? Can I start working on it?

···

On Sun, 10 Apr 2016 at 23:07, Howard Lovatt via swift-evolution < swift-evolution@swift.org> wrote:

Do it to them all: flatMapped, unioned, etc.

On Monday, 11 April 2016, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:

on Fri Apr 08 2016, Brent Royal-Gordon <swift-evolution@swift.org> wrote:

>> The 'flatten()' method didn't get the Swift 3 API renaming treatment
>> it should have, to go along with reversed, sorted, joined, etc.
>> As I see Dmitri Gribenko already agree with it but we still have to
>> discuss it here. So what do you think?
>
> I'm in favor.
>
> Though all of these things are terms of art, not all terms of art are
created equal. For instance:
>
> * `map` is supported by virtually any language which have any of these
> higher-order functions, and to my knowledge the name `map` is
> universally used.
> * `reduce` is not quite as universally supported, but it's still very
> common, and most (but not quite all) languages with higher-order
> functions support it.
> * `filter` is very widely supported, but the *name* `filter` is not
> quite so consistent. Ruby, for instance, calls it `select`, Perl calls
> it `grep`, etc.
> * `takeWhile` lies on the other end of the spectrum, being very
narrowly supported.
>
> In my opinion, it would be a really bad idea to rename `map` or
> `reduce`; `filter` is probably a bad idea but not terrible; but we
> should feel relatively free to rename `takeWhile`.
>
> `flatten` is nowhere near as weak a term of art as `takeWhile`, but I
> think it still falls towards that end of the spectrum. We shouldn't
> worry too much about changing it. `map`, `reduce`, and `filter` are
> much stronger terms, and we should be more cautious about changing
> them.

The problem is flatMap. The semantics of map, flatMap, and flatten are
inextricably linked. IMO it would be weird to do this to one or two of
these names and not to all of them.

--
Dave

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
-- Howard.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Totally agree with Brent, map/flatMap are terms of art.

···

Sent from my iPad

On 10 Apr 2016, at 23:11, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

I still don’t see what’s being lost here, it’s not like the proposal is to radically rename them, all we’d end up with is .mapped(), .flattened(), .filtered() etc., which any good search engine should still be able to find, and will still come up in auto-completion if you start typing .map, .flatten and so-on. I just don’t see the point of even having naming conventions if we allow outside influences to force exceptions for IMO fairly weak reasons; it amounts to the “because everyone else is doing it” reasoning, but again, it’s not as if someone used to using .map is going to be suddenly lost and confused when presented with .mapped() instead.

As someone who has been using `map` for virtually my entire programming career, across languages as different as Perl, Haskell, Ruby, Objective-C (with my own categories) and now Swift, I would be as surprised by a `map` named `mapped` as I would be by a letter addressed to "Brented".

The naming exception is simple and principled: When other languages have universally adopted a given name, and there's nothing particularly wrong with that name except that it doesn't match Swift conventions, don't fight the trend just to be different, or just to be self-consistent. People would figure out `mapped`, sure, but `map` causes not even a moment of confusion.

Do you also think that trigonometry should be `foo.sined`, `foo.cosined`, and `foo.tangented`? Or maybe `foo.sine`, `foo.cosine`, and `foo.tangent`, with corresponding `foo.formSine`, `foo.formCosine`, and `foo.formTangent` functions?

Remember the first and most important sentence in the API Guidelines: "Clarity at the point of use is your most important goal." If there is a universally-accepted nomenclature for a particular operation, the clearest thing we can do is to adopt it, even if it doesn't match our normal guidelines.

Consistency is a powerful and satisfying goal, but we must be careful not to be seduced by it. "A foolish consistency is the hobgoblin of little minds." When there is a compelling reason to deviate from the guidelines, we should be prepared to do so.*

Consistency in API naming is a means to convey semantics, not an end in itself. We must not let the cart be put before the horse.

(Besides, since they take arguments, we should favor `mapping`, `filtering`, `flatMapping`, etc. Or perhaps even `mappingFlattened` for the last one. Can you see the rabbit hole we're beginning to tumble down?)

* Well, as the people writing the guidelines, we should try to modify the guidelines to write a general rule accommodating the deviation, because any situation we encounter is likely to be encountered by others as well. We've done that in this case by writing the "term of art" rule.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution