On 6 February 2012 10:49, a <a@a.com> wrote:
On Saturday, 4 February 2012 at 23:15:17 UTC, Manu wrote:

First criticism I expect is for many to insist on a class-style vector
library, which I personally think has no place as a low level, portable API.
Everyone has a different idea of what the perfect vector lib should look
like, and it tends to change significantly with respect to its application.

I feel this flat API is easier to implement, maintain, and understand, and
I expect the most common use of this lib will be in the back end of peoples
own vector/matrix/linear algebra libs that suit their apps.

My key concern is with my function names... should I be worried about name
collisions in such a low level lib? I already shadow a lot of standard
float functions...
I prefer them abbreviated in this (fairly standard) way, keeps lines of
code short and compact. It should be particularly familiar to anyone who
has written shaders and such.

I prefer the flat API and short names too.


Opinions? Shall I continue as planned?

Looks nice. Please do continue :)

You have only run this on a 32 bit machine, right? Cause I tried to compile this simple example and got some errors about converting ulong to int:

True, I have only been working in x86 GDC so far, but I just wanted to get feedback about my approach and API design at this point.
It seems there are no serious objections, I'll continue as is. I have an ARM compiler too now, so I'll be implementing/testing against that as reference also.
 
auto testfun(float4 a, float4 b)
{
  return swizzle!("yxwz")(a);
}

It compiles if I do this changes:

566c566
<               foreach(i; 0..N)
---
               foreach(int i; 0..N)
574c574
<                               int i = countUntil(s, swizzleKey[0]);
---
                               int i = cast(int)countUntil(s, swizzleKey[0]);
591c591
<                                       foreach(j, c; s) // find the offset of the ---
                                       foreach(int j, c; s) // find the offset of the