withoutFirst()
withoutLast()

-Thorsten

> Am 29.12.2015 um 21:43 schrieb Kevin Ballard via swift-evolution 
> <swift-evolution@swift.org>:
> 
> Actually that's not true, CollectionType does not define dropFirst(). It 
> merely provides a default implementation. dropFirst() is only actually 
> defined in SequenceType, which does not have any mutating methods. Renaming 
> it to "removingFirst()" would be against the guidelines for all sequences 
> that are not also RangeReplaceableCollectionTypes.
> 
> -Kevin Ballard
> 
> On Tue, Dec 29, 2015, at 12:39 PM, Daniel Duan wrote:
>> I made the same observation on Haskell in the original post :)
>> 
>> “removeFirst()” is also defined in CollectionType. So “dropFirst()” is 
>> removeFirst()’s – in the Guidelines’ term – "non-mutating counterpart" for 
>> all CollectionTypes. Therefore, “removingFirst()” would be the winner.
>> 
>> (My personal preference notwithstanding, that is).
>> 
>>> On Dec 29, 2015, at 12:15 PM, Kevin Ballard <ke...@sb.org> wrote:
>>> 
>>> I guess that's a good argument for keeping "prefix" and "suffix" instead of 
>>> "take" and "takeEnd". But there is no good noun phrase to use for 
>>> dropFirst/dropLast (Haskell's "init" and "tail" are nouns but they're very 
>>> confusing and don't really make sense once you add in an integral argument 
>>> anyway). The guidelines do say it's acceptable to use an imperative verb if 
>>> there is no good noun phrase, so "skip" and "skipEnd" (or "skipLast", or 
>>> maybe "skipSuffix" if we're keeping "suffix") are still reasonable.
>>> 
>>> Incidentally, it occurs to me that "removingFirst" is actually not an 
>>> appropriate name here, because dropFirst is a method of SequenceType, and 
>>> SequenceType does not have mutating methods. removeFirst is actually 
>>> defined by RangeReplaceableCollectionType (and by Set, and also by 
>>> CollectionType if SubSequence == Self).
>>> 
>>> -Kevin Ballard
>>> 
>>> On Tue, Dec 29, 2015, at 11:55 AM, Daniel Duan wrote:
>>>> Hi Kevin,
>>>> 
>>>> “take" and “skip” are fine as free function names. As method names, they 
>>>> are a step back from following the API Guidelines (“non-mutating methods 
>>>> should read as noun phrases”).
>>>> 
>>>> - Daniel
>>>> 
>>>>> On Dec 29, 2015, at 11:40 AM, Kevin Ballard via swift-evolution 
>>>>> <swift-evolution@swift.org> wrote:
>>>>> 
>>>>> On Mon, Dec 28, 2015, at 04:23 PM, Kevin Ballard wrote:
>>>>>> That said, `droppingFirst` sounds pretty weird to me. "drop" (and the 
>>>>>> related verb "take" that we're not using) has precedent in multiple 
>>>>>> languages (Rust and Haskell come to mind) to mean "return a new sequence 
>>>>>> that skips the first N elements". And I'm not aware of any language that 
>>>>>> sets precedent for the verb "drop" to mean "mutate the receiver".
>>>>> 
>>>>> Hmm, I just took a look, and while Rust does use "take", it actually 
>>>>> doesn't use "drop" (but Haskell does). Instead it uses "skip", which 
>>>>> seems like a good candidate if we're going to rename this. I'm tempted to 
>>>>> say we should use "take" instead of "prefix" as well, because 
>>>>> `seq.prefix(3)` isn't actually immediately obvious what it does (as the 
>>>>> verb "prefix" usually means to add onto the front, not to take the 
>>>>> front). And we can use "takeLast" for "suffix" (neither Rust nor Haskell 
>>>>> appears to have an equivalent of takeLast; I believe Rust doesn't because 
>>>>> none of its iterator adaptors use dynamically-allocated memory, and I 
>>>>> think Haskell expects you to just do `reverse . take n . reverse`). 
>>>>> Although I do notice Haskell has a function dropWhileEnd that drops the 
>>>>> suffix, which suggests "takeEnd" and "dropEnd" here.
>>>>> 
>>>>> Which is to say, if we're going to rename these methods, my vote is:
>>>>> 
>>>>> prefix -> take
>>>>> suffix -> takeEnd or takeLast
>>>>> dropFirst -> skip
>>>>> dropLast -> skipEnd or skipLast
>>>>> 
>>>>> -Kevin Ballard
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution@swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> 
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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

Reply via email to