how to do iota(0,256) with ubytes ?
and more generally:
iota with 'end' parameter set to max range of a type.

of course this doesn't work:
auto b=iota(ubyte(0), ubyte(256));
//cannot implicitly convert expression (256) of type int to ubyte

Could we have a function with iota_inclusive that has inclusive bounds for 'end' parameter ?

On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
> how to do iota(0,256) with ubytes ?
> and more generally:
> iota with 'end' parameter set to max range of a type.
>
> of course this doesn't work:
> auto b=iota(ubyte(0), ubyte(256));
> //cannot implicitly convert expression (256) of type int to ubyte
>
> Could we have a function with iota_inclusive that has inclusive bounds for 'end' parameter ?

A bounds parameter would be nice, like in std.random.uniform.


For anyone googling for a solution to this, here's a workaround:

auto b = iota(0, 256).map!"cast(ubyte)a";

Unfortunately this doesn't scale to iterating over all values of long or ulong.

On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
> On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
>> how to do iota(0,256) with ubytes ?
>> and more generally:
>> iota with 'end' parameter set to max range of a type.
>>
>> of course this doesn't work:
>> auto b=iota(ubyte(0), ubyte(256));
>> //cannot implicitly convert expression (256) of type int to ubyte
>>
>> Could we have a function with iota_inclusive that has inclusive bounds for 'end' parameter ?
>
> A bounds parameter would be nice, like in std.random.uniform.
>
>
> For anyone googling for a solution to this, here's a workaround:
>
> auto b = iota(0, 256).map!"cast(ubyte)a";
>
> Unfortunately this doesn't scale to iterating over all values of long or ulong.

ugh, didn't see other people had posted the same response, the thread got split...

On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
> On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
>> how to do iota(0,256) with ubytes ?
>> and more generally:
>> iota with 'end' parameter set to max range of a type.
>>
>> of course this doesn't work:
>> auto b=iota(ubyte(0), ubyte(256));
>> //cannot implicitly convert expression (256) of type int to ubyte
>>
>> Could we have a function with iota_inclusive that has inclusive bounds for 'end' parameter ?
>
> A bounds parameter would be nice, like in std.random.uniform.
>
>
> For anyone googling for a solution to this, here's a workaround:
>
> auto b = iota(0, 256).map!"cast(ubyte)a";
>
> Unfortunately this doesn't scale to iterating over all values of long or ulong.

Do not use string lambdas. It will be deprecated.

map!(a => cast(uint)a) is correct

On Sunday, 11 October 2015 at 13:58:24 UTC, Temtaime wrote:
> On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
>> On Friday, 9 October 2015 at 02:41:50 UTC, Timothee Cour wrote:
>>> how to do iota(0,256) with ubytes ?
>>> and more generally:
>>> iota with 'end' parameter set to max range of a type.
>>>
>>> of course this doesn't work:
>>> auto b=iota(ubyte(0), ubyte(256));
>>> //cannot implicitly convert expression (256) of type int to ubyte
>>>
>>> Could we have a function with iota_inclusive that has inclusive bounds for 'end' parameter ?
>>
>> A bounds parameter would be nice, like in std.random.uniform.
>>
>>
>> For anyone googling for a solution to this, here's a workaround:
>>
>> auto b = iota(0, 256).map!"cast(ubyte)a";
>>
>> Unfortunately this doesn't scale to iterating over all values of long or ulong.
>
> Do not use string lambdas. It will be deprecated.

I'm pretty sure that's not going to happen. Could you point me to something that supports that statement? I know there a few people who *want* them to be deprecated/removed, but that's a very different matter from "will be deprecated".

On Sunday, 11 October 2015 at 15:34:38 UTC, John Colvin wrote:
> On Sunday, 11 October 2015 at 13:58:24 UTC, Temtaime wrote:
>> Do not use string lambdas. It will be deprecated.
>
> I'm pretty sure that's not going to happen. Could you point me to something that supports that statement? I know there a few people who *want* them to be deprecated/removed, but that's a very different matter from "will be deprecated".

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.

- Jonathan M Davis

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)

?

On Monday, 12 October 2015 at 08:20:12 UTC, Per Nordlöw wrote:
> What about adding an overload supporting
>
>     iota!ubyte(0, 256)
>
> ?

Ahh, already present of course, according to declaration

auto iota(B, E)(
  B begin,
  E end
)
if (isIntegral!(CommonType!(B, E)) || isPointer!(CommonType!(B, E)));

This will make `B` be ubyte and `E` be int.

I guess current behaviour is to return a range where `ElementType` is `CommonType!(ubyte, int)` which is `int`.

On Friday, 9 October 2015 at 07:20:43 UTC, John Colvin wrote:
> For anyone googling for a solution to this, here's a workaround:
>
> auto b = iota(0, 256).map!"cast(ubyte)a";

Without string lambdas:

    auto b = iota(0, 256).map!(a => cast(ubyte)a);

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.

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.