>> This sounds reasonable. However, please realize that if you wish to use
>> the short vector names (i.e. float4, float3, float2, etc) you should support
>> the full set with a decent range of operations and methods. Several people
>> (myself included) have written similar short vector libraries; I think
>> having having short vectors in phobos is important, but having one library
>> provide float4 and another float2 is less than ideal, even if not all of the
>> types could leverage the SMID backend. For myself, the killer feature for
>> such a library would be have the CUDA compatible alignments for the types.
>> (or an equivalent enum to the effect)
>
>
> I can see how you come to that conclusion, but I generally feel that that's
> a problem for a higher layer of library.
> I really feel it's important to keep std.simd STRICTLY about the hardware
> simd operations, only implementing what the hardware can express
> efficiently, and not trying to emulate anything else. In some areas I feel
> I've already violated that premise, by adding some functions to make good
> use of something that NEON/VMX can express in a single opcode, but takes SSE
> 2-3. I don't want to push that bar, otherwise the user will lose confidence
> that the functions in std.simd will actually work efficiently on any given
> hardware.
> It's not a do-everything library, it's a hardware SIMD abstraction, and most
> functions map to exactly one hardware opcode. I expect most people will want
> to implement their own higher level lib on top tbh; almost nobody will ever
> agree on what the perfect maths library should look like, and it's also
> context specific.
I think that having the low-level vectors makes sense. Since