Repository navigation
[de-feature request] tuples for const-defined dimensions #622
Description
Activity
Hi @swfsql, and welcome to the ecosystem!
Will you please provide more information about the motivation for doing this? I generally find it convenient to use
5instead of(5,)and haven't experienced any problems with this. If you want to use(usize,)as the type instead ofusize, that's supported too.Thanks @jturner314 ,
I initially got motivated when I called.dim()I expected a(usize,)return type - as an inexperienced user - since I was used to understand tuple length as dimension quantity after using the crate for a while.This specific change - the return type of
dim()- doesn't implies the additional change about building dimension information - about usingusizeor(usize,)for dimension construction - but I thought that for symmetry, if one change happened, the other should follow.I hope this helps clarifying - and I'd like to restate that this is a pretty subjective ergonomic opinion from an inexperienced user! (and this change would surely be not welcomed for most users I believe)
Oh, okay, you're talking about
Ix1::Pattern. I misunderstood. (I should have read the PR.)Now that Rust supports destructuring fixed-size arrays in addition to tuples, I actually think we should change all the
Dimension::Patterntypes for const-dimensions from tuples to fixed-size arrays, so we'd haveIx0::Pattern = [usize; 0]Ix1::Pattern = [usize; 1]Ix2::Pattern = [usize; 2]- ...
Ix6::Pattern = [usize; 6]IxDyn::Pattern = IxDyn
Length-one arrays are syntactically nicer than one-element tuples because they don't need the extra trailing comma. Additionally, arrays are more convenient than tuples because they can be iterated over easily.
@swfsql, @LukeMathWalker, @bluss Thoughts?
Reacted by Thiago Machado, Joshua Ellis and bluss@jturner314 I've submitted a PR for reference.
The changes were pretty straightforward and I personally think it's user-friendly to always use arrays for constant dimensions. But it still required a lot of changes, so this still would be a drastic change, api-wise.Sorry for the delay in answering, but it's quite an intense period.
The change itself looks pretty good to me.
On the other hand though, are we gaining enough from this change considering its breaking one of the core interfaces?I know we have plans to review the way the whole dimension story works, and those plans will probably have to take into account the new language features that we could use to make the API nicer (e.g. const generics and GAT, for this specific case). Should we repeatedly iterate on this section of the API or should we try to batch improvements together?
Reacted by Thiago Machado@LukeMathWalker I personally would enjoy the change but I agree, I don't it's worth for other users.
And for everyone, surely, it wound't worth to have a drastic API change that is destined to be changed again.On the other hand, I think there is a chance that the interface (exclusively) pushed by const generics would likely be this very change (tuples -> fixed-sized arrays). But a more drastic re-design may change it completely, so there would really be no-gains for this change.
I think that we will end up switching from tuples to fixed-size arrays anyway when we overhaul the
Dimensiontypes. However, @LukeMathWalker makes a good point that since this change isn't urgent, we should wait to make it at the same time as all the other breaking changes to theDimensiontypes.So, let's postpone this until we overhaul the
Dimensiontypes. That is currently blocked on const generics, specialization, and generic associated types. Fortunately, the Rust roadmap includes all of those features for this year.Reacted by Thiago Machado and Ivan Smirnov
updated to #622 (comment)
(so tuples replacement for arrays, and also still using arrays for 0-sized and 1-sized dimensions)
Hello, I'm new to this ecosystem here- and thanks a lot for your work on it!
As I was using the
ndarraycrate - it may be just me but - I thought that "what if we always use a tuple to indicate a shape's dimension?".I mean, this is already how it works most of the time, except for the
Ix1and the dynamic case.That is, the only case, for compile-time defined number of dimensions, that doesn't fall into what I said above was the
Ix1case, where a singleusizeis used as aPatternto indicate a 1-dimensional array.I propose a de-featuring (feature removal) so that
Ix1case would also require a 1-sized tuple, similarly to theIx2(Ix3, etc) cases.This would simply increase verbosity whenever a
Ix1were to be used, so.. well.. maybe this [proposal] would be taking a step into the wrong direction.(I'll be PRing for a reference since this would require simple changes after all).