> Am 17.10.2017 um 00:15 schrieb Adam Kemp <adam_k...@apple.com>:
>
>
>>> On Oct 16, 2017, at 3:08 PM, Thorsten Seitz <tseit...@icloud.com> wrote:
>>>
>>> 2. It’s generally useful to be able to ask if two objects that you can
>>> iterate over are equal by comparing the elements in the order that they’re
>>> iterated over.
>>
>> Here I disagree. This operation only makes sense if the iteration order has
>> underlying well defined semantics. Otherwise the result of that operation
>> will be a random value, depending on the undefined order. I argue that this
>> is never useful. That is why I am asking for a use case for that.
>
> I deliberately didn’t specify in either of these cases whether the thing was
> ordered or not. I’m not disputing that this only makes sense for ordered
> things. I’m merely pointing out that making that distinction is impractical
> for other reasons.
>
>> There are several solutions for this, e.g. covariant redefinition of the
>> result type to be ordered in an ordered subclass, or more sophisticated
>> solutions which could even allow to chose the result type if required to be
>> different from a default.
>> The latter would allow e.g. mapping over a Set to commonly result in a
>> generic Iterable but in some cases it might also result in another Set. The
>> same holds for mapping over an ordered collection like an Array. The result
>> might commonly be an array but it might also be a Set or something else.
>> Swift currently lacks the necessary capabilities in the type system to
>> achieve this, though, so we would have to stay with the current solution
>> that `map` always returns an Array (at least for the moment) — which already
>> is not very satisfactory in itself.
>
> Now you’re inventing new language features in order to support your proposed
> solution to a problem that I still have seen no evidence to support being a
> significant source of real bugs. And those new language features would still
> result in a library and language that is harder to use than before. This is
> not a convincing argument for making a change.
The new language features (which are sorely needed anyway) are not necessary
for the proposed solution of splitting the protocol. They are necessary to fix
or improve the definition of map which is currently lacking as well because it
always returns an Array.
Alternatively we can continue to live with that. This is a separate question.
-Thorsten
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
