On Monday, 12 October 2015 at 09:24:12 UTC, Marc Schütz wrote:
> On Sunday, 11 October 2015 at 21:31:27 UTC, Jonathan M Davis wrote:
>> Their use is discouraged at this point, but they're used by so much code that I'd be very surprised if they were ever deprecated. And until we have a solution for being able to compare non-string lambdas for equality, they're _defintely_ not going to be deprecated. Regardless, AFAIK, neither Walter nor Andrei has ever stated that they will be removed from Phobos - just that we want to move towards using the newer style lambdas instead.
>
> Besides, `reduce!"a+b"` and `map!"a*a"` are more concise than the lambda versions and can therefore be preferable in some situations.

Yeah. I like them, but if it weren't for the fact that regular lambdas can't be compared, it would probably be being pushed as bad practice to use string lambdas. They were already removed from all of the std.algorithm docs because of that. They generally seem to be considered a failure that has been replaced by the shorter lambda syntax that we copied from C#.

- Jonathan M Davis

On Monday, 12 October 2015 at 08:38:39 UTC, Per Nordlöw wrote:
> I would suggest to turn this pattern into a new algorithm typically called
>
>     iotaOf(T, B, E)(B begin, E end);
>
> called as
>
>     iotaOf!ubyte(0,256)
>
> and use `std.conv.to` instead.

Here's a solution:

https://github.com/nordlow/justd/blob/a8b733034b049dc2abeabaa37332e503f39e9066/range_ex.d#L434

On 10/09/2015 04:41 AM, Timothee Cour via Digitalmars-d wrote:
>
> Could we have a function with iota_inclusive that has inclusive bounds
> for 'end' parameter ?
>

iota!"[]" ?

On 10/12/15 11:20 AM, Per Nordlöw wrote:
> On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
>> of course this doesn't work:
>> auto b=iota(ubyte(0), ubyte(256));
>> //cannot implicitly convert expression (256) of type int to ubyte
>
> What about adding an overload supporting
>
>      iota!ubyte(0, 256)

We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei

On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
> We can add iota!T() with no arguments that spans the entire range of T (integral). -- Andrei

Clever, as always, Andrei! ;)

Should I do a PR?

that's only a partial fix:
I also would like to express:

iotaInclusive(1,256)
iotaInclusive(1,256,3)

etc



On Mon, Oct 12, 2015 at 12:31 PM, Nordlöw via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
>
>> We can add iota!T() with no arguments that spans the entire range of T
>> (integral). -- Andrei
>>
>
> Clever, as always, Andrei! ;)
>
> Should I do a PR?
>

On 10/12/15 10:31 PM, Nordlöw wrote:
> On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
>> We can add iota!T() with no arguments that spans the entire range of T
>> (integral). -- Andrei
>
> Clever, as always, Andrei! ;)
>
> Should I do a PR?

Guess I'd pull it. Flattery will take you anywhere :o). -- Andrei

On 10/12/15 10:55 PM, Timothee Cour via Digitalmars-d wrote:
> that's only a partial fix:
> I also would like to express:
>
> iotaInclusive(1,256)

iota!ubyte.drop(1)

> iotaInclusive(1,256,3)

iota!ubyte.drop(1).stride(3)

Just playing devil's advocate.


Andrei

On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:
> Guess I'd pull it. Flattery will take you anywhere :o). -- Andrei

Got it.

On Monday, 12 October 2015 at 20:39:11 UTC, Andrei Alexandrescu wrote:
>> Alexandrescu wrote:
>>> We can add iota!T() with no arguments that spans the entire range of T
>>> (integral). -- Andrei

From a quick glance I couldn't find a way to reuse the existing overloads. Can anybody come with a reusing solution?