I actually think we should use ‘mapped’, ‘filtered’, and ‘reduced’ instead of the “Terms of Art”. They start with the same words, so anyone looking for ‘map’, ‘filter’, and ‘reduce’ will see them in the autocomplete.
The signatures are also different, so:
let newList = list.map(…)
would throw an error because I have the signature wrong. Given the consistent naming rules, ‘mapped’ will be tried fairly quickly (especially with auto-complete). If we are extra worried, we could put in a diagnostic/fixit to teach the ‘mapped’, etc… version.
Seems like needless (and confusing) inconsistency otherwise...
Thanks,
Jon
···
> What is the rationale behind the name dropFirst()? Being a non-mutating method it should clearly be e.g. droppingFirst() according to the API Naming Guidelines.
Like many `Sequence` and `Collection` operations, `dropFirst()` is a result of the "term of art" exception, which is implied by the "Use Terminology Well" section of the API Guidelines: <Swift.org - API Design Guidelines;
Many languages use `dropWhatever` or `drop_whatever` for operations which return some sort of list with some of its leading or trailing elements removed. For instance:
* Ruby (which I happen to have in Dash) has `drop(n)` and `drop_while` methods.
* Haskell has `drop n`, `dropWhile`, and `dropWhileEnd` functions.
* Scala has a `drop(n)` method.
* R has a `dropFirst` function.
The standard library has chosen to break its usual patterns in order to maintain consistency with languages like these.
Personally, I believe the term of art exception has been misapplied in this area of the language; the precedents are not very strong, and the resulting APIs form a patchwork of inconsistent names rather than a coherent family. The term of art exception increases the clarity of calls like `map` and `filter` where the names are truly universal, but it impedes the clarity of the whole family of `first`/`prefix`/`suffix`/`last` calls, and the names should be revisited and rationalized. But that hasn't happened yet.
I mean that *IF* we were to rename ‘map’ to ‘mapped’, the compiler would catch this and could recommend the new name. Even if we add a mutating version called ‘map’, it would still catch this case because the mutating version would have a void return.
Thanks,
Jon
···
On Jun 16, 2016, at 4:57 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
The signatures are also different, so:
let newList = list.map(…)
would throw an error because I have the signature wrong.
I'm not sure what you mean by this. What is the error? Why? Does it have something to do with the code you imagine is elided by the ellipses?
…Thus, I don’t really see the harm in renaming these to match the rest of Swift. It won’t cause any confusion that can’t be easily recovered from. I was outvoted on that though…
Thanks,
Jon
···
On Jun 16, 2016, at 5:01 AM, Jonathan Hull <jhull@gbis.com> wrote:
I mean that *IF* we were to rename ‘map’ to ‘mapped’, the compiler would catch this and could recommend the new name. Even if we add a mutating version called ‘map’, it would still catch this case because the mutating version would have a void return.
Thanks,
Jon
On Jun 16, 2016, at 4:57 AM, Brent Royal-Gordon <brent@architechies.com> wrote:
The signatures are also different, so:
let newList = list.map(…)
would throw an error because I have the signature wrong.
I'm not sure what you mean by this. What is the error? Why? Does it have something to do with the code you imagine is elided by the ellipses?
I’ve always considered the term of art argument to be at least partially a red herring.
These methods are difficult because you don’t have guarantees of non-mutability until you get to Collection - on Sequence, a dropFirst method may mean that neither the original nor returned sequence can address that item anymore. Names have to indicate that a Sequence may or may not consume an item.
It makes me wonder if we should evaluate doing something more aggressive, such as eliminating the support of one-time/destructive Sequences completely.
-DW
···
On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Thu Jun 16 2016, Jonathan Hull <swift-evolution@swift.org> wrote:
…Thus, I don’t really see the harm in renaming these to match the rest
of Swift. It won’t cause any confusion that can’t be easily recovered
from.
Hmm, after some consideration I think we should reconsider renaming all of
the exceptions (map => mapped, filter => filtered, etc).
The main reason to use a term of art is such that people already familiar
with the term will immediately understand it. However as Jonathan points
out, since the modified terms are very close to the terms of art they are
unlikely to hinder in this objective and any initial confusion would be
very quickly and easily recovered from. Any mental pattern matching would
quickly transfer to the Swift forms.
– Basically* all benefits of using a term of art still apply.*
– The likelihood, duration and impact of any confusion would all be very
low.
– It'd be a lot more consistent (which also aids the mind to learn to
pattern match on -ed/-ing).
···
On Thu, Jun 16, 2016 at 5:51 PM, David Waite via swift-evolution < swift-evolution@swift.org> wrote:
I’ve always considered the term of art argument to be at least partially a
red herring.
These methods are difficult because you don’t have guarantees of
non-mutability until you get to Collection - on Sequence, a dropFirst
method may mean that neither the original nor returned sequence can address
that item anymore. Names have to indicate that a Sequence may or may not
consume an item.
It makes me wonder if we should evaluate doing something more aggressive,
such as eliminating the support of one-time/destructive Sequences
completely.
-DW
> On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
> on Thu Jun 16 2016, Jonathan Hull <swift-evolution@swift.org> wrote:
>
>> …Thus, I don’t really see the harm in renaming these to match the rest
>> of Swift. It won’t cause any confusion that can’t be easily recovered
>> from.
>
> I'm beginning to think you may be right.
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
That is something I've been considering, too. Another possibile
approach, though I admit I don't really understand how this one plays
out yet, would be to break the refinement relationship between Sequence
and Collection.
···
on Thu Jun 16 2016, David Waite <david-AT-alkaline-solutions.com> wrote:
I’ve always considered the term of art argument to be at least partially a red herring.
These methods are difficult because you don’t have guarantees of
non-mutability until you get to Collection - on Sequence, a dropFirst
method may mean that neither the original nor returned sequence can
address that item anymore. Names have to indicate that a Sequence may
or may not consume an item.
It makes me wonder if we should evaluate doing something more
aggressive, such as eliminating the support of one-time/destructive
Sequences completely.
Hmm, after some consideration I think we should reconsider renaming all of the exceptions (map => mapped, filter => filtered, etc).
The main reason to use a term of art is such that people already familiar with the term will immediately understand it. However as Jonathan points out, since the modified terms are very close to the terms of art they are unlikely to hinder in this objective and any initial confusion would be very quickly and easily recovered from. Any mental pattern matching would quickly transfer to the Swift forms.
– Basically all benefits of using a term of art still apply.
– The likelihood, duration and impact of any confusion would all be very low.
– It'd be a lot more consistent (which also aids the mind to learn to pattern match on -ed/-ing).
I believe my points still apply - Sequences may be one time use and thus mutating (such as a socket-backed Sequence). Neither mapped() nor mapping() is universally appropriate.
-DW
···
On Jun 16, 2016, at 11:40 AM, Patrick Pijnappel <patrickpijnappel@gmail.com> wrote:
On Thu, Jun 16, 2016 at 5:51 PM, David Waite via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I’ve always considered the term of art argument to be at least partially a red herring.
These methods are difficult because you don’t have guarantees of non-mutability until you get to Collection - on Sequence, a dropFirst method may mean that neither the original nor returned sequence can address that item anymore. Names have to indicate that a Sequence may or may not consume an item.
It makes me wonder if we should evaluate doing something more aggressive, such as eliminating the support of one-time/destructive Sequences completely.
-DW
> On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
> on Thu Jun 16 2016, Jonathan Hull <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> …Thus, I don’t really see the harm in renaming these to match the rest
>> of Swift. It won’t cause any confusion that can’t be easily recovered
>> from.
>
> I'm beginning to think you may be right.
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
I agree the essence of the "terms of art" can still exist in the base name
while applying the "ed/ing rule". I would vote to have these renamed to
better align with Swift and less with the terms of art.
-Shawn
···
On Thu, Jun 16, 2016 at 10:41 AM Patrick Pijnappel via swift-evolution < swift-evolution@swift.org> wrote:
Hmm, after some consideration I think we should reconsider renaming all of
the exceptions (map => mapped, filter => filtered, etc).
The main reason to use a term of art is such that people already familiar
with the term will immediately understand it. However as Jonathan points
out, since the modified terms are very close to the terms of art they are
unlikely to hinder in this objective and any initial confusion would be
very quickly and easily recovered from. Any mental pattern matching would
quickly transfer to the Swift forms.
– Basically* all benefits of using a term of art still apply.*
– The likelihood, duration and impact of any confusion would all be very
low.
– It'd be a lot more consistent (which also aids the mind to learn to
pattern match on -ed/-ing).
On Thu, Jun 16, 2016 at 5:51 PM, David Waite via swift-evolution < > swift-evolution@swift.org> wrote:
I’ve always considered the term of art argument to be at least partially
a red herring.
These methods are difficult because you don’t have guarantees of
non-mutability until you get to Collection - on Sequence, a dropFirst
method may mean that neither the original nor returned sequence can address
that item anymore. Names have to indicate that a Sequence may or may not
consume an item.
It makes me wonder if we should evaluate doing something more aggressive,
such as eliminating the support of one-time/destructive Sequences
completely.
-DW
> On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution < >> swift-evolution@swift.org> wrote:
>
>
> on Thu Jun 16 2016, Jonathan Hull <swift-evolution@swift.org> wrote:
>
>> …Thus, I don’t really see the harm in renaming these to match the rest
>> of Swift. It won’t cause any confusion that can’t be easily recovered
>> from.
>
> I'm beginning to think you may be right.
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
On Thu, Jun 16, 2016 at 8:56 PM, Shawn Erickson <shawnce@gmail.com> wrote:
I agree the essence of the "terms of art" can still exist in the base name
while applying the "ed/ing rule". I would vote to have these renamed to
better align with Swift and less with the terms of art.
-Shawn
On Thu, Jun 16, 2016 at 10:41 AM Patrick Pijnappel via swift-evolution < > swift-evolution@swift.org> wrote:
Hmm, after some consideration I think we should reconsider renaming all
of the exceptions (map => mapped, filter => filtered, etc).
The main reason to use a term of art is such that people already familiar
with the term will immediately understand it. However as Jonathan points
out, since the modified terms are very close to the terms of art they are
unlikely to hinder in this objective and any initial confusion would be
very quickly and easily recovered from. Any mental pattern matching would
quickly transfer to the Swift forms.
– Basically* all benefits of using a term of art still apply.*
– The likelihood, duration and impact of any confusion would all be very
low.
– It'd be a lot more consistent (which also aids the mind to learn to
pattern match on -ed/-ing).
On Thu, Jun 16, 2016 at 5:51 PM, David Waite via swift-evolution < >> swift-evolution@swift.org> wrote:
I’ve always considered the term of art argument to be at least partially
a red herring.
These methods are difficult because you don’t have guarantees of
non-mutability until you get to Collection - on Sequence, a dropFirst
method may mean that neither the original nor returned sequence can address
that item anymore. Names have to indicate that a Sequence may or may not
consume an item.
It makes me wonder if we should evaluate doing something more
aggressive, such as eliminating the support of one-time/destructive
Sequences completely.
-DW
> On Jun 16, 2016, at 8:45 AM, Dave Abrahams via swift-evolution < >>> swift-evolution@swift.org> wrote:
>
>
> on Thu Jun 16 2016, Jonathan Hull <swift-evolution@swift.org> wrote:
>
>> …Thus, I don’t really see the harm in renaming these to match the rest
>> of Swift. It won’t cause any confusion that can’t be easily recovered
>> from.
>
> I'm beginning to think you may be right.
>
> --
> -Dave
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution