On 28 April 2015 at 06:42, John Colvin via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > 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 complicated. It's something I had done in this other code >>> and >>> showing for example. >> >> >> >> Yeah, see I don't feel making a simple thing like an array into >> something more complex by wrapping it in templates is ever a good >> thing to do. >> I just think it's a missed opportunity that the compiler doesn't >> support any of this in the language. >> >> It would appear at face value to be a great opportunity for lowering. >> Assignment can lower to .copy(), operators can lower to map!(...) > > > builtin slicesopSliceAssign (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 it's own syntax.
The only reason I considered it workable was because an operator expression is generally meaningless without an assignment to the left; "a[] = b[]*2;", so the mul could conceivably be expressed in a lazy sense, since it will be evaluated immediately by the assignment. Array operations passed as arguments to functions are already not allowed in the usual case, so I think it would be fine in this instance... it's impossibly for an array operation to have any meaning without a final assignment (I think?)