Lokathor / tinyvec

Just, really the littlest Vec you could need. So smol.
https://docs.rs/tinyvec
Apache License 2.0
648 stars 49 forks source link

Support `[value; N]` syntax with non-matching sizes #123

Closed Nemo157 closed 4 years ago

Nemo157 commented 4 years ago
let vec: TinyVec<[f32; 4]> = tiny_vec![1.1; 3];

currently fails with:

8 |     let vec: TinyVec<[f32; 4]> = tiny_vec![1.1; 3];
  |              -----------------   ^^^^^^^^^^^^^^^^^ expected an array with a fixed size of 4 elements, found one with 3 elements
  |              |
  |              expected due to this

but using tiny_vec![1.1, 1.1, 1.1] in the same location works, also should be supported:

let vec: ArrayVec<[f32; 4]> = array_vec![1.1; 3];
let vec: TinyVec<[f32; 4]> = tiny_vec![1.1; 5];

And should check the error message for this to make sure it's still good:

let vec: ArrayVec<[f32; 4]> = array_vec![1.1; 5];
Lokathor commented 4 years ago

I'm looking at this, and i'm looking at the macro_rules! code, and i'm not sure how to make this change happen.

As far as I can tell, there's no way for the macro_rules! to figure out what type (in terms of array length) the output is desired to be.

So we'd have to make a default, and then use a loop to push the element over and over or something? Does that sound right? Does that sound good?

Nemo157 commented 4 years ago

Yeah, I think the implementation would have to end up being something like that (or iter::repeat($el).count($count).collect() or similar); and then rely on the optimizer to turn that into just a memset.

Lokathor commented 4 years ago

I'm worried that the collect wouldn't know what to type infer to any more.

I'd generally prefer a limited macro use that always gives correct type inference without extra info over a macro that does extra fancy stuff but you have to type annotate.

Lokathor commented 4 years ago

Yeah, checked just now,

  ($elem:expr; $n:expr) => {
    //$crate::ArrayVec::from([$elem; $n])
    ::core::iter::repeat($elem).take($n).collect()
  };

this makes the type inference fail all over.

EDIT: take, not count, but it's still an inference failure