[swift-evolution] API Guidelines: dropFirst?

Patrick Pijnappel patrickpijnappel at gmail.com
Thu Jun 16 12:40:44 CDT 2016


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 at 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 at swift.org> wrote:
> >
> >
> > on Thu Jun 16 2016, Jonathan Hull <swift-evolution at 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160616/cf90f1c4/attachment.html>


More information about the swift-evolution mailing list