Variadic generics - pre-RFC

Look into the examples, I did exactly that with Display.

yes.

Also, from the previous discussion of this, it was noted that tuples don’t necessarily contain contiguous parts of memory that would represent a sub-tuple. For example, (i32, u32, f32) does not have to have a sub-tuple (u32, f32).

Because of this, how would this be handled.

let tuple: (i32, u32, f32) = (-1, 0, 2.0);
let (x, ..xs) = &tuple;

Specifically, what is the type of xs?

See the Destructuring part. xs would be of type (&u32, &f32).

Ok, I asked because that’s slightly different because you are passing the tuple by value, not a reference to the tuple. Thanks for the reply.

1 Like

If I understand correctly you think abstract-tuple-types are not required, because you could also add syntax, which talks about all elements of a tuple. Correct me, if I understood wrong.

Something like this was my initial idea, but how would you eg. define associated types, which have to be tuples? Currently this works with type A: (T;T); This is required as otherwise you could never use .. onto an associated type, as you would not know whether the associated type is a tuple-type.

We don’t have generic associated types yet, and if and when we do get them we will have where bounds on associated types. Therefore, bounds on tuple types could be defined earlier in the impl using where bounds.

impl<*T> Trait for Foo<T>
where T: Clone {
   type Assoc = T;
}

Do you mean I should create a PR to my own repository?

Hm… I don’t quite understand. How would you define the following without this syntax?

trait Foo {
    type A: (T;T);
}

(T; T) isn’t a trait, right? So you can’t use it as a bound.

... does not have any conflict with ranges.

1 Like

... is valid in match patterns. Proof.

I recognize I could have been more explicit about this, but yes (T; T) is a trait or shall at least behave like a trait.

Mostly to check I’m following the meaning of * correctly, these are all functionally equivalent function signatures, correct?

fn foo(a: u32, b: u32)
fn foo(a: u32, *(b,): (u32,))
fn foo(*(a, b): (u32, u32))

And this is different in that the type of b will be (u32,) instead of u32, but externally the function will appear to have the same signature?

fn foo(a: u32, *b: (u32,))

It has been deprecated in favor of 0..=20 and this has nothing to do with the intended syntax for variadics ...Stuff/Stuff...

2 Likes

Yes.

Yes, it's deprecated but it's still there in stable, and will not be removed.

I can think of uses for variadics in match patterns, so it does have to do with variadics.

Ok, in that case I see your point.

I would expect to have to type foo(..arg: i32), not ..arg: (i32;). I’m not sure if that would mean it would need to desugar into something else, but.

Sorry, I’m a little confused about this. ^^ How would I create a pull request, without even having a fork?

Not really, this could be removed after the 2021 edition.

What I mean is there's no syntactical conflict between the range usage a...b and the variadic usage ...X. It makes no sense to interpret a...b which unfolds either a or b. The parser could unambiguously interpret $expr ... $expr as a range pattern, and ... $tt as an unfold.

2 Likes