Should Dictionary support first related methods from Collection conformance?

[Tino]

@dabrahams

Hopefully this will provide some perspective

That's great! I'm not as unhappy with the status quo as it might have seemed, though ;-)
Especially, I found the link to https://github.com/apple/swift-evolution/blob/master/proposals/0065-collections-move-indices.md to be quite useful, as it shows a simple remedy for awkward repetition like someStringWithAQuiteLongName[someStringWithAQuiteLongName.index(after: someStringWithAQuiteLongName.firstIndex(of: ".")!)]

@dabrahams

I'm not sure what you're arguing for here, but I consider the fact that dropLast and suffix are exposed on Collection to be design bugs caused by the fact that Collection refines Sequence (which is flawed).

I just wanted to express that I understand the motivation to disallow certain operations, and it seems that we share some concerns regarding Sequence:

@dabrahams

• I disagree with the premise that finite vs. infinite is a fundamental concept that should be represented in the type system , because there exist finite collections that are, for all practical purposes, infinite. Take for example the finite collection 0...Int64.max : there is almost no operation you'd want to statically disallow for an infinite collection but that should be used on this value of Range<Int64> .

That's true indeed. Ultimately, I think this isn't about infinity at all, but rather about "is it too large to fit in a computer", and this question has no clear answer.
Without the suffix-methods, it would be much less controversial that a Sequence can have no end.

@dabrahams

Single- vs multi-pass is captured: that's the distinction between Sequence and Collection . As I noted in the posting you referenced , the notion of single-pass is not really well-representable

Luckily, I didn't claim to have a plan to resolve that one ;-) - but maybe the introduction of move-only types could be a opportunity to "fix" Sequence?

@dabrahams

SortedCollection is not needed for binary search. In fact, you want a binary search that doesn't require sortedness to be represented in the type system, because it should be possible to binary search in an Array after it has been sorted.

No, I personally don't want Array.binarySearch ;-) - and I'm pretty sure that I don't need it, because it hasn't been there the last years.
I think it also wouldn't be consistent to allow arrayThatIsntSortedAtAll.binarySearch(element) despite the fact how unhappy many people are that they can't do stringThatsReallyOnlyBoringASCII[5] ;-).

But I better stay out of this discussion, as I found someone who is way more qualified than me:

@dabrahams

They should be scoped to a kind of collection that bundles
the predicate with the elements, e.g.

let x = Sorted([3, 4, 1, 5, 2], >) // stores a sorted copy of the array

(-: just joking here - that message starts with the disclaimer that it's posted on behalf of others)