I'm not saying that the shuffles would have to be generated using the field names - that would be near impossible.
For example: ~~~ #[simd] struct RGB <T> { r: T, g: T, b: T, a: T } ~~~ Shuffling would still use the CL syntax: ~~~ let v2 = v.s3201 ~~~ I would be really interested to hear what sanxiyn had in mind for #[simd] when he added it. Relevant PRs with discussions: https://github.com/mozilla/rust/pull/5841 https://github.com/mozilla/rust/pull/6214 https://github.com/mozilla/rust/pull/7705 ~Brendan On 16/07/2013, at 9:06 PM, Jens Nockert <j...@nockert.se> wrote: > On H.25/07/16, at 12:13, Brendan Zabarauskas <bjz...@yahoo.com.au> wrote: > >>> Introducing a new t, ty_simd_vec(t, uint), instead of using the current >>> #[simd] struct { … }, is yet another thing that is controversial about the >>> patch >> >> This is indeed a shame because named fields are very nice for clean, >> self-documenting apis. Perhaps properties solve this, but I don't think >> there would be much will to add more features considering all the work that >> still has to be done (I could be wrong though). > > While nice, I don't think this is a good idea. > > It leads to very complex shuffle-syntax, and makes intrinsics and anything > else with a T1 (x T1) -> T2 type signature (comparisons, non-bitwise casts) > much harder to call and implement. > > It would also mean that all intrinsics would have to be generic. And that you > need to pattern-match match in trans to generate shufflevector operations. > > Examples, > > ~~~ OpenCL shuffle > let v2 = v.abgr; > ~~~ Named property shuffle > let v2 = match v1 { rgba { r:r, b:b, g:g, a:a } => rgba { r:a, g:b, b:g, a:r > } }; > ~~~ > > And that isn't even the degenerate case of wanting to replace the order of a > subset of the elements of a u8x16-like type which succintly can be described > in OpenCl-like syntax. > > ~~~ > v1.s89 = v1.s98; // or for complex arithmetic > let i0 = a * b; > r.even = i0.even - i0.odd; > r.odd = a.odd * b.even + a.even * b.odd; > ~~~ > > And these I cannot write the named-property variants of on my phone, so you > will have to imagine what they would look like. > _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev