colour lib needs reviewers

[John Colvin via Digitalmars-d]

On Tuesday, 13 September 2016 at 09:31:53 UTC, Manu wrote:
> On 13 September 2016 at 17:47, John Colvin via Digitalmars-d 
> <digitalmars-d at puremagic.com> wrote:
>> On Tuesday, 13 September 2016 at 01:05:56 UTC, Manu wrote:
>>>>
>>>> Also can I swizzle channels directly?
>>>
>>>
>>> I could add something like:
>>>   auto brg =  c.swizzle!"brg";
>>>
>>> The result would be strongly typed to the new arrangement.
>>
>>
>> Perfect use-case for opDispatch like in gl3n.
>
> One trouble with arbitrary swizzling is that people often want 
> to
> write expressions like "c.xyzy", or whatever, but repeating
> components... and that's not something my colours can do. It's 
> useful
> in realtime code, but it doesn't mean anything, and you can't
> interpret that value as a colour anymore after you do that.
> This sort of thing is used when you're not actually storing 
> colours in
> textures, but instead just some arbitrary data. Don't use a 
> colour
> type for that, use a vector type instead.
> What that sort of swizzling really is, are vector operations, 
> not
> colour operations. Maybe I could add an API to populate a 
> vector from
> the components of colours, in-order... but then we don't 
> actually have
> linear algebra functions in phobos either! So colour->vectors 
> and
> arbitrary swizzling is probably not something we need 
> immediately.
>
> In my lib, colours are colours. If you have `BGR8 x` and `RGB8 
> y`, and add them, you don't get x.b+y.r, x.g+y.g, x.r+y.b... 
> that's not a colour operation, that's an element-wise vector 
> operation.

Fair enough, you know much better than me how useful it would be. 
I was just suggesting that if you do support some sorts of 
swizzling then opDispatch would allow you to avoid users having 
to use strings. It would be as simple to implement as `alias 
opDispatch = swizzle;` given the swizzle function you were using 
before.