On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote:
> I couldn't easily find how to make the module work with allocators. IMO combining this module with std.experiemtal.allocator should be possible. And if it is already possible, there should be tests for documentation and validation.

https://github.com/D-Programming-Language/phobos/pull/3397#issuecomment-157652959

On Tuesday, 17 November 2015 at 18:38:14 UTC, Ilya Yaroshenko wrote:
> Thanks! Implemented: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-4f243752aee5ecc098ce1c36eedd86a2/web/phobos-prerelease/std_experimental_range_ndslice.html#byElement
>
> --Ilya

Fantastic! Thx, for the quick response.

On Tuesday, 17 November 2015 at 18:38:14 UTC, Ilya Yaroshenko wrote:
>> AFAIK, if all the slice dimensions are know at compile-time it should. This is kind of similar to how std.range.chain() works.
>
> Thanks! Implemented: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-4f243752aee5ecc098ce1c36eedd86a2/web/phobos-prerelease/std_experimental_range_ndslice.html#byElement
>
> --Ilya

I don't see any other checks using `isRandomAccessRange`. Surely there must be other ranges/algorithms in ndslice that should propagate random access, right?

On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote:
> I couldn't easily find how to make the module work with allocators. IMO combining this module with std.experiemtal.allocator should be possible. And if it is already possible, there should be tests for documentation and validation.

I have added makeSlice, however this function can be easily implemented by user: allocate array -> pass array to `sliced`.

updated docs http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-ce47155797f387348826317811c4af0c/web/phobos-prerelease/std_experimental_range_ndslice.html
--Ilya

On Wednesday, 18 November 2015 at 10:18:37 UTC, Nordlöw wrote:
> On Tuesday, 17 November 2015 at 18:38:14 UTC, Ilya Yaroshenko wrote:
>>> AFAIK, if all the slice dimensions are know at compile-time it should. This is kind of similar to how std.range.chain() works.
>>
>> Thanks! Implemented: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-4f243752aee5ecc098ce1c36eedd86a2/web/phobos-prerelease/std_experimental_range_ndslice.html#byElement
>>
>> --Ilya
>
> I don't see any other checks using `isRandomAccessRange`. Surely there must be other ranges/algorithms in ndslice that should propagate random access, right?

Only Slice and ByElements has random access. Special check was added for internal PtrShell, however it is commented with `version(none)` because it works only with git compiler (I have fixed std.internal.test.dummyrange ).

There was check using `isRandomAccessRange` after range primitives in Slice. I have added `hasLength` and `hasSlicing` too https://github.com/D-Programming-Language/phobos/commit/919009dce8903eca1ded119036ed5b2dd5bfcaa5

Updated docs: http://dtest.thecybershadow.net/artifact/website-7a646fdea76569e009844cdee5c93edab10980ca-3429854b54bfa5eb7060de221b45056f/web/phobos-prerelease/std_experimental_range_ndslice.html

-- Ilya

On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote:
> I couldn't easily find how to make the module work with allocators. IMO combining this module with std.experiemtal.allocator should be possible. And if it is already possible, there should be tests for documentation and validation.

I know it's bad practice for regular Phobos code to import from std.experimental, but what's the protocol for code inside std.experimental importing other code in std.experimental? It would be nice to get Andrei's opinion on this.

Another problem with using std.experimental.allocator is it ties the time table of this going into stable with std.allocator. Worse case scenario, it could be a year before std.allocator is stable, where as std.range.ndslice is much simpler code and could be moved much faster.

On Wednesday, 18 November 2015 at 18:40:40 UTC, Jack Stouffer wrote:
> On Wednesday, 18 November 2015 at 08:52:11 UTC, Robert burner Schadek wrote:
>> [...]
>
> I know it's bad practice for regular Phobos code to import from std.experimental, but what's the protocol for code inside std.experimental importing other code in std.experimental? It would be nice to get Andrei's opinion on this.
>
> Another problem with using std.experimental.allocator is it ties the time table of this going into stable with std.allocator. Worse case scenario, it could be a year before std.allocator is stable, where as std.range.ndslice is much simpler code and could be moved much faster.

Possible solutions:
1. Mark `makeSlice` with red "Experimental"
2. Move `makeSlice` to unittest, so user could copy-past it.

On Wednesday, 18 November 2015 at 19:25:04 UTC, Ilya wrote:
> Possible solutions:
> 1. Mark `makeSlice` with red "Experimental"
> 2. Move `makeSlice` to unittest, so user could copy-past it.

Another solution is to leave `makeSlice` in std.experimental when std.experimental.range.ndslice is moved to stable and move it to std.range when std.experimental.allocator is moved.

I think it would be best to get someone from the leadership's opinions on this before a decision is made.

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.
>
> [...]

I don't see any constraint related to dimenssion checking.

On Wednesday, 18 November 2015 at 20:10:00 UTC, Lucien Janvier wrote:
> 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.
>>
>> [...]
>
> I don't see any constraint related to dimenssion checking.

I have add description to asserts https://github.com/9il/phobos/commit/f91d611ad66af9b6698142f92bcb8cc05747aff0

Is it constraints you asked?