[swift-evolution] Proposal: Implement == and < for tuples where possible, up to some high arity

[Dmitri Gribenko]

On Mon, Dec 7, 2015 at 12:22 PM, Kevin Ballard <kevin at sb.org> wrote:
> On Mon, Dec 7, 2015, at 12:01 PM, Dmitri Gribenko wrote:
>
> On Mon, Dec 7, 2015 at 11:48 AM, Kevin Ballard via swift-evolution
> <swift-evolution at swift.org> wrote:
> Good question. What's the best way to measure this? File size of
> build/$target/swift-macosx-x86_64/lib/swift/macosx/libswiftCore.dylib (does
> that even include generic functions)? Or the x86_64/libswiftCore.dylib from
> the same folder (what's the difference)? Or x86_64/Swift.swiftmodule?
> Something else?

Use utils/cmpcodesize.

The swift-macosx-x86_64/lib/swift/<target>/libswiftCore.dylib dylibs
are fat ones, the dylib nested inside the architecture directory is a
regular one.  Please also measure for iOS (to build those, run
build-script with -i).

> I personally don't see a point in going as high as 12 tuple elements.  About
> 4 or 5 makes sense to me.  Given that Swift does not have variadic generics
> right now, these long tuples have to be defined by someone manually.  If one
> is defining a tuple that is that long, I'd argue that they should be using a
> custom struct instead.
>
>
> Depends on how much code size it is. I'd rather err on the side of defining
> it for a higher arity tuple than we expect people to actually use in
> practice. Just because it's probably a good idea to not point more than a
> handful of elements in a tuple doesn't mean people will actually stick to
> that, and it's surprising behavior to have == suddenly break because you
> added one more (Equatable) value to the tuple. As an example, my coworker
> recently wrote some code that uses a tuple of 7 elements (as a typedef). It
> probably should have been a struct, but I think it was originally defined
> with just 3 or 4 elements and sprouted the others as he worked on it.
> Granted, this particular tuple wouldn't actually support ==, but I'm sure
> others have written similarly long tuples.
>
> I'll probably prototype this some time today, and I can produce some
> measurements of code size at different arities (if I can figure out the best
> way to measure that).

I can see that.  Definitely depends on the code size, though!

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/