> I suggest allowing a concatenated type (Tuple[*Ts, *Ts2]) when the *length* of at least one is unambiguously implied by other arguments.
I think that's reasonable, if no one has any objections on the grounds that we make things too hard for static checkers. I've tentatively reworked the section in question to reflect this.
> Regarding concatenation on classes, I do think there's a way to add extra contexts via method calls:
Oh, huh, interesting. But not being able to actually write down unambiguously exact what type it is seems like a major downside. Having to consult the constructor arguments to figure out the type also seems really complicated. At the moment I'm leaning towards not allowing it - unless anyone has any suggestions of a concrete use case for `class C(Generic[*Ts1, *Ts2])`?
> The idea does not need any sort of dependent typing, just to take advantage of literal types.
Oh, super cool! Looking forward to seeing more of this :)
> However, I might have missed something but: where is specified the constraints that a variadic can have (variance, bound...)?
Ah, yeah - variance and bound are currently not supported. I think figuring out how they should work is going to be tricky, so best left for a future PEP, once we have more experience with using variadic generics in practice. I've added a short section stating this explicitly.
> And the subtyping rules for variadics?
Do you mean something like this?
```python
DType = TypeVar('DType')
Shape = TypeVarTuple('Shape')
class Array(Generic[DType, *Shape]): ...
class Float32Array(Array[np.float32, *Shape]): ...
```
If so, hopefully this should be clear from the new section on 'An Ideal Array Type'. If you mean something different, could you clarify?
---
One significant change I've (tentatively) made is renaming `Expand` to `Unpack`, to reflect the terminology we use with regular tuples. I'm surprised no one else has suggested this, so I might be missing something - are there any arguments against calling what we're doing 'unpacking'?