Formal Review of std.range.ndslice

[Ilya Yaroshenko via Digitalmars-d]

On Monday, 16 November 2015 at 22:45:35 UTC, Jack Stouffer wrote:
> This is the start of the two week formal review for the 
> proposed std.range.ndslice. This new addition to the standard 
> library would add the ability to create and manipulate 
> multi-dimensional random access ranges in a way that will be 
> very familiar to those of you who use numpy. This has the 
> potential to give D a huge boost in popularity in numerical and 
> scientific applications.
>
> A quick run down for those that are not familiar with the 
> process. After two weeks, the PR author (Ilya Yaroshenko) will 
> have time to make proposed changes. Then, when the author feels 
> it's ready, the PR will go to a vote. In the vote, everyone in 
> the community has a say, but if one of the main contributors or 
> maintainers has a very negative opinion (for example) that will 
> carry more weight.
>
> Github: 
> https://github.com/D-Programming-Language/phobos/pull/3397
> dub: http://code.dlang.org/packages/dip80-ndslice
> docs: 
> http://dtest.thecybershadow.net/results/bac6211c1d73b2cf62bc18c9844c8c82c92c21e1/5c6071ca953cf113febd8786b4b68916cbb2cdaf/
>
> previous discussion: 
> http://forum.dlang.org/thread/rilfmeaqkailgpxoziuo@forum.dlang.org


## Guide for Slice/Matrix/BLAS contributors

1. Pay _unprecedented_ attention to functions to be
        a. inlined(!),
        b. `@nogc`,
        c. `nothrow`,
        d. `pure`.
     95% of functions will be marked with `pragma(inline, true)`. 
So, use
     _simple_ `assert`s with messages that can be computed at 
compile time.
     The goals are:
         1. to reduce executable size for _any_ compilation mode
         2. to reduce template bloat in object files
         3. to reduce compilation time
         4. to allow a user to write an extern C bindings for code 
based on `Slice`.

2. Do not import `std.format`, `std.string` and `std.conv` to 
format error
     messages.`"Use" ~ Concatenation.stringof ~ ", really ."` Why? 
Please,
     read [1] again.

3. Try to use already defined `mixin template`s for pretty error 
messaging.

4. Do not use `Exception`s/`enforce`s to check indexes and 
length. Exceptions are
     allowed only for algorithms where validation of an input data 
is
     significantly complex for user. `reshaped` is a good example 
where
     Exceptions are required. Put an example of Exception handing 
and workaround
     for function that can throw.

5. Do not use compile time flags for simple checks like 
transposition
     of a matrix. It is much better to have runtime matrix 
transposition.
     Furthermore, Slice provide runtime matrix transposition out 
of the box.

6. Do not use _Fortran_VS_C_ flags. They are about notation,
     but not about algorithm itself. To care about math world 
users add
     appropriate code example in the documentation. `transposed` / 
`everted`
     can be used for cash friendly code.

7. Do not use compile time power of D to produce dummy entities 
like
     `IdentityMatrix`.

8. Try to separate allocation and algorithm logic whenever 
possible.

9. Add CTFE unittests to new functions.

---

Update docs:
http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-87c7c7a1a6e59a71179301c54d012057/web/phobos-prerelease/std_experimental_range_ndslice.html

-- Ilya