Why doesn't this chain of ndslices work?

[Seb via Digitalmars-d-learn]

On Saturday, 14 May 2016 at 21:59:48 UTC, Stiff wrote:
> Here's the code that doesn't compile:
>
> import std.stdio, std.experimental.ndslice, std.range, 
> std.algorithm;
>
> void main()
> {
> 	auto alloslice = [1, 2, 3, 4].sliced(1,4);
> 	auto sandwich = chain(alloslice,
> 		(0).repeat(8).sliced(2,4),
> 		alloslice);
> 	writeln(sandwich);
> }
>
> If I comment out the line with the repeat, or allocate the 
> repeat with .array(), everything is fine. I get that the types 
> are incompatible in some way, but it seems like I should be 
> able to lazily instantiate those zeros whenever I need to 
> (later). Should this work? Is there a different way to set up 
> all of the ranges without allocating everything up front?
>
> And yeah, resources aren't particularly limited for my 
> application, so allocating everything wouldn't hurt, but I'm 
> trying to really understand all of these little details about 
> ranges. I love them when they work, but the learning curve has 
> been steep.


Your problem is that the slices don't have the same type. If you 
allocate the array, the slice has the type int*, whereas iota and 
repeat are different types - see this example:

```
auto a = iota(1, 8).sliced(2,4);
auto b = (0).repeat(8).sliced(2,4);
pragma(msg, CommonType!(typeof(a), typeof(b))); // void
```

```
auto a = iota(1, 8).array.sliced(2,4);
auto b = (0).repeat(8).array.sliced(2,4);
pragma(msg, CommonType!(typeof(a), typeof(b))); // Slice!(2LU, 
int*)
```

> Is there a different way to set up all of the ranges without 
> allocating everything up front?

The newest version of mir (dev version of ndslice) supports 
sparse slices - see e.g.:
http://docs.mir.dlang.io/latest/mir_sparse.html

I also opened an issue to support chain/concatenate for normal 
slices (https://github.com/libmir/mir/issues/213).

Feel free to post further questions about mir directly on our 
issue tracker on Github or on the Gitter chat.