Okay, so that wasn’t quite as easy as I thought when I started writing
the email.
That also allocates two intermediate arrays (the inputs to zip()).
And relies on all variables having the same type.
Both true. What actually happened was, when I looked at the tuple version, I thought “okay, that’s basically just zipping the two together and then running < on each pair". In trying to write the email making that point, I discovered that this “easy” alternative is actually ridiculously complicated once you translate it from a vague notion to running code, and thought that was funny.
Okay, so that wasn’t quite as easy as I thought when I started writing
the email.
That also allocates two intermediate arrays (the inputs to zip()).
And relies on all variables having the same type.
Both true. What actually happened was, when I looked at the tuple version, I thought “okay, that’s basically just zipping the two together and then running < on each pair". In trying to write the email making that point, I discovered that this “easy” alternative is actually ridiculously complicated once you translate it from a vague notion to running code, and thought that was funny.
Then you may be able to do something like this:
func ==<A:tuple<>, B: tuple<>, where A: Equatable, B:Equatable>(lhs:
tuple<A,B>, rhs: tuple<A,B>) {
return ls.prefix() as A == rhs.prefix() as A && lhs.suffix() as B ==
rhs.suffix() as B
}
extension tuple<Equatable,Equatable>: Equatable {}
The downside I can see for that is that it will match the same tuple n
different ways. You can overcome this by only allowing tuple<A,B> to append
a single element, but it's less useful. Alternatively it will always match
the function with the most elements in the left-most argument, and cannot
match against the empty tuple.
···
On Tue, Dec 8, 2015 at 11:18 AM, Dmitri Gribenko via swift-evolution < swift-evolution@swift.org> wrote:
On Mon, Dec 7, 2015 at 4:17 PM, Brent Royal-Gordon > <brent@architechies.com> wrote:
>>>> return zip([a1,b1,c1,d1,e1],
[a2,b2,c2,d2,e2]).lazy.filter(==).first.flatMap(<) ?? false
>>>>
>>>> Okay, so that wasn’t quite as easy as I thought when I started writing
>>>> the email.
>>>
>>> That also allocates two intermediate arrays (the inputs to zip()).
>>
>> And relies on all variables having the same type.
>
> Both true. What actually happened was, when I looked at the tuple
version, I thought “okay, that’s basically just zipping the two together
and then running < on each pair". In trying to write the email making that
point, I discovered that this “easy” alternative is actually ridiculously
complicated once you translate it from a vague notion to running code, and
thought that was funny.
We have lexicographicalCompare(), so it is not that complicated after all.