Impl traits for specific array lengths above 32

[withoutboats]

Its occurred to me that while not having impls for arbitrary array lengths is a problem, probably the practical use cases of arrays of length over 32 is not evenly distributed among all the possible lengths. That is, there is probably a small number of additional impls we could define which would unblock an outsized portion of users.

For example, we could implement traits for all arrays of a length that is an exponents of 2 up to 4096 (chosen because in bytes its the smallest page size on most systems). That is, for 64, 128, 256, 512, 1024, 2048, and 4096 - only 7 additional impls.

It might also be good to implement for the standard multiples of ten - 50, 100, 250, 500, 1000 (5 impls).

However, I never actually need large arrays, so I could be off base. Does anyone who runs into this problem have any feedback? Are there specific array lengths that could be targeted that you think would help many use cases?

[dtolnay]

serde-rs/serde#573 wanted [T; 386]. The prime factors are 2 and 193.

Anyway, this seems like a more reasonable version of what typenum is doing here which is:

• Numbers 0 through 1024
• Powers of 2 below u64::MAX
• Powers of 10 below u64::MAX

@paholg any thoughts on how we could get the most bang for the buck here?

[paholg]

Um, if you’re asking what values to pick, I dunno. For typenum, powers of 2 and 10 seemed useful, and 1000ish seemed like a good stopping place. For arrays, I would think the most useful values would be 33, 34, … counting up. Perhaps looking at what values people use for generic-array would give some insight.

If you’re asking how to generate them, typenum uses a build script, but that’s probably not useful here. I think generating the impls for an array is just a macro call with that number, which isn’t really possible for typenum.

[GolDDranks]

I’d imagine that lengths used commonly in cryptography would see some use. The current impls cover those up to 256 bits (32xu8), but array lengths of 48, 64, 128, 256, 384 and 512 would be nice to have.

[kornel]

While supporting arrays for more sizes would be nice, it would also make them even weirder (users would be wondering why does it work for 64, but not 65 elements!?).

There’s work on fully generic constants in types, which would make it work for all array sizes:

https://github.com/rust-lang/rfcs/issues/1930

[withoutboats]

There’s work on fully generic constants in types, which would make it work for all array sizes:

I know This is intended as a stopgap.

[lang-team-minutes] Const generics

On Thursday at the language team meeting we discussed const generics, both in terms of RFC 1931 and the work that eddyb has done and plans to do on the const system. First, the tl;dr version: We believe that we can have an RFC accepted and const generics available on nightly by the end of 2017. :tada: We discussed the major outstanding issues, which have to do with the theory of equality we use in type checking. I'll summarize the discussio below. One thing we want to throw to the community…

[kornel]

Are const generics a replacement/generalization of pi types?

I’m surprised there’s talk about supporting expressions. For me, for an MVP, just bare integers would suffice.

[eddyb]

It’s not harder to support them (as long as we treat them as opaque), and we have to anyway for [T; expr].

[withoutboats]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.