) are map!(e=...), and that's a lot of boilerplate
surrounding '...', obscuring the actual operation.
I also find the paren nesting gets pretty deep (for instance, the map
above) and the code is harder to follow than a traditional foreach
loop.
If we can do normal array operations on ranges
On 4/26/2015 3:17 AM, Manu via Digitalmars-d wrote:
Array operations are super cool, and I'm using ranges (which kinda
look and feel like arrays) more and more these days, but I can't help
but feel like their incompatibility with the standard array operations
is a massive loss.
Let's say I want
can implement it.
Lowering array operations to lazy ranges seems like a huge can of
worms. Not so keen. Lazy array ops are great, but I don't see it
working out as a builtin feature unless it had it's own syntax.
On Monday, 27 April 2015 at 06:52:11 UTC, Manu wrote:
On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Phobos containers already support the first line, and it
would be a
natural extension to make them support the second.
Sure, it's not
On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Phobos containers already support the first line, and it would be a
natural extension to make them support the second.
Sure, it's not complicated. It's something I had done in this other code and
Phobos containers already support the first line, and it would
be a natural extension to make them support the second.
Sure, it's not complicated. It's something I had done in this
other code and showing for example.
On Monday, 27 April 2015 at 06:52:11 UTC, Manu wrote:
On 27 April 2015 at 15:58, Vlad Levenfeld via Digitalmars-d
digitalmars-d@puremagic.com wrote:
Phobos containers already support the first line, and it
would be a
natural extension to make them support the second.
Sure, it's not
(and opSliceOpAssign) understanding ranges as
source operands is a good idea. I might even see if I can implement it.
Lowering array operations to lazy ranges seems like a huge can of worms. Not
so keen. Lazy array ops are great, but I don't see it working out as a
builtin feature unless it had
On Sunday, 26 April 2015 at 10:17:59 UTC, Manu wrote:
Array operations are super cool, and I'm using ranges (which
kinda
look and feel like arrays) more and more these days, but I
can't help
but feel like their incompatibility with the standard array
operations
is a massive loss.
Let's say I
Array operations are super cool, and I'm using ranges (which kinda
look and feel like arrays) more and more these days, but I can't help
but feel like their incompatibility with the standard array operations
is a massive loss.
Let's say I want to assign one range to another: b[] = a[];
It's not
Naturally, where I wrote: float[] a = b.transform[];
I meant: float[N] a = b.transform[]; // -- on the stack
On 26 April 2015 at 20:17, Manu turkey...@gmail.com wrote:
Array operations are super cool, and I'm using ranges (which kinda
look and feel like arrays) more and more these days, but I
On Sunday, 26 April 2015 at 10:17:59 UTC, Manu wrote:
I find that my lazy ranges often end up on the stack, but I
can't
assign/initialise directly: float[] a = b.transform[];
Instead I need to: float[] a; b.transform.copy(a[]);
To enable the first line, builtin arrays would need to be able
Manu, I just saw your other post clarifying the code was float[N]
a = ..., not float[] a. That changes things a bit.
I just implemented a static array type in the lib (1-d only for
now) which can do the following:
unittest {
import std.range: only;
StaticArray!(int, 2) x;
On Sunday, 26 April 2015 at 18:48:15 UTC, Vlad Levenfeld wrote:
I've got a lib to enable this syntax:
Array!float a = b[].transform_1;
a[i..j] = c[x..y].transform_2;
Phobos containers already support the first line, and it would be
a natural extension to make them support the second.
14 matches
Mail list logo
