I'm blowing the dust off my colour proposal implementation. I want to get it into a state where it may be accepted into std.experimental, but I'm having trouble deciding on the scope of the initial offering. Some people are arguing for 'complete', and I tend to argue for minimal/un-contentious. It can grow in the future as desired.
There is a slightly blurry line separating a colour lib from an image lib, and I want to focus the boundaries. My design propositions are this: 1. Colour type definitely belongs in the std library; - Colour types and conversions are hard to implement, non-experts almost always get it wrong. - Implementation is more-or-less un-contentious, I don't think there's much room for debate in terms of API design. - It's an enabler for a lot of further library work. 2. Image processing probably doesn't belong in the std library, at least, not right now; - There are so many ways the API could look, no particular one is objectively 'correct'. - We need time for conventions to proliferate before API decisions for the std lib can reasonably be decided. 3. I am kinda drawing the line between 'colour' and 'image' at the point you find yourself working with buffers of data. Ie, 'colour' is strictly @nogc. So, I guess that means this clearly encompasses colour types, primitive operations, and then typical functions like interpolation, and conversion. I think that's the scope, and I'm happy with that definition, but it raises some questions... Colour defined this way without buffered enhancements will be inefficient; performing single-colour operations in series is not cool. Image operations tend to want support for simd, loop unrolling, etc, for efficient image library implementations. I don't really feel it's the place for an image library to re-define these efficient array versions of colour operations... so, should they be in the base colour library? This problem actually extends beyond colours... D positions ranges as a core language mechanic, and I've often struggled with this problem that defining an element type and how it behaves and using it in a range is frequently not an efficient implementation. It's the classic OOP design fail, but dressed up differently. What is the current wisdom with respect to implementing efficient batch implementations for various element types? I'm feeling like I should not attempt to address this problem in the initial colour library and just leave it as simple as possible; just the colour type. It can be used for inefficient purposes for now (and produce *correct* results) and we can worry about efficient batch processing in a follow up, or when an image library comes along? I have another question too; some of the operations are algorithmic in nature. Take lerp for example. Interpolation may appear in an algorithm, which means we should have a standard API for interpolation for all possible types, and modules just provide implementations for the types they introduce. There should be default implementations in phobos for builtin types. Where does this belong? (I haven't found one to already exist) I feel like `lerp(T, F)(T a, T b, F t) { return a*(1-t) + b*t; }` belongs kinda near min/max... but std.algorithm.comparison doesn't feel right. I think a small suite of functions like this exists.