Initial feedback for std.experimental.image

[Rikki Cattermole via Digitalmars-d]

On 7/07/2015 3:34 a.m., ponce wrote:
> On Monday, 6 July 2015 at 13:48:53 UTC, Rikki Cattermole wrote:
>> If reviewing the code itself is too much of a hassel, please review
>> the specification document.
>> http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_specification.html
>>
>>
>
>
>> Use the Cartesian coordinates system using two (X and Y) size_t integers
>
> Why not just int? There is preciously little addressable images beyond
> 2^31. size_t has a variable size and is a source of build breaking.
> Also, please no unsigned integers! This create all manners of bugs
> because of how integer promotion work.

I've been sold on the unsigned vs signed type issue for and only for the 
x and y coordinates.
Although I'm a little concerned about not using ptrdiff_t instead of a 
specific integral type. For the time being, I'll alias it and use that 
instead. This will need to be decided later on.

Offsets will still be size_t. As it would be too limiting.

>> A major concern for D is templated code. Template bloat as it is known
>> is when there is large amounts of templates being initiated with vast
>> array of compile time arguments. For this very reason, template usage
>> must be constrained to the bare minimum. Keeping in line with other D
>> code of highly reusable code, templates will be used. Be constrained
>> to colors (usage not definition) and constructors as much as possible.
>
> I don't think there is so much problems with Phobos levels of
> meta-programming. There are also way to reduce template instantiation
> with type-punning.
>
> To me an image library should be based on a static interface with
> optionally a wrapper to auto-generate the dynamic interface much like in
> std.allocator. Is it the case? Your library seem to be based around the
> dynamic 'interface' instead.

I choose structs primarily for my types because it can be optimized away 
and also allocated on stack instead of the heap.
If people prefer classes they can and are more than welcome to use them. 
There are interfaces for just this purpose identical to ranges.
Only like ranges there is no point on just relying on it.

Instead I have SwappableImage struct. Which allows with no allocation to 
wrap up any image storage type you wish via the constructor. I am very 
proud of this. 
http://cattermole.co.nz/phobosImage/docs/html/std_experimental_image_interfaces.html#.SwappableImage