## digitalmars.D - how to do iota(0,256) with ubytes ? (cf need for iotaInclusive)

Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
```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 ?
```
Oct 08 2015
John Colvin <john.loughran.colvin gmail.com> writes:
```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.
```
Oct 09 2015
John Colvin <john.loughran.colvin gmail.com> writes:
```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
```
Oct 09 2015
Temtaime <temtaime gmail.com> writes:
```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
```
Oct 11 2015
John Colvin <john.loughran.colvin gmail.com> writes:
```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".
```
Oct 11 2015
Jonathan M Davis <jmdavisProg gmx.com> writes:
```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

- Jonathan M Davis
```
Oct 11 2015
Marc =?UTF-8?B?U2Now7x0eg==?= <schuetzm gmx.net> writes:
```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

Besides, `reduce!"a+b"` and `map!"a*a"` are more concise than the
lambda versions and can therefore be preferable in some
situations.
```
Oct 12 2015
Jonathan M Davis <jmdavisProg gmx.com> writes:
```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

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
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
```
Oct 12 2015
Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```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)

```
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```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)

Here's a solution:

https://github.com/nordlow/justd/blob/a8b733034b049dc2abeabaa37332e503f39e9066/range_ex.d#L434
```
Oct 12 2015
Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```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

iota!ubyte(0, 256)

?
```
Oct 12 2015
Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```On Monday, 12 October 2015 at 08:20:12 UTC, Per Nordlöw wrote:

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`.
```
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
```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

iota!ubyte(0, 256)

We can add iota!T() with no arguments that spans the entire range of T
(integral). -- Andrei
```
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```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?
```
Oct 12 2015
Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
```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=C3=B6w 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?

```
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
```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)

Andrei
```
Oct 12 2015
Timothee Cour via Digitalmars-d <digitalmars-d puremagic.com> writes:
```On Mon, Oct 12, 2015 at 1:41 PM, Andrei Alexandrescu via Digitalmars-d <
digitalmars-d puremagic.com> wrote:

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)

That's not a good workaround; it's error-prone in more general cases:

auto fun(ubyte a, ubyte stride){
// return iotaInclusive(a,256, stride);// simple
// error prone with your suggestion:
auto b=some function of a, stride;
return iota!ubyte.drop(b).stride(stride);
}

Andrei

```
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
```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
```
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```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.
```
Oct 12 2015
=?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
```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?
```
Oct 12 2015
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
```On 10/12/15 11:51 PM, Nordlöw wrote:
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?

One possibility (can't look at the code now) is to change the
implementation to use a closed interval for state, then use that. But
then you still need to mind overflow. Whole range is just a bit special
like that. -- Andrei
```
Oct 12 2015
Jacques =?UTF-8?B?TcO8bGxlcg==?= <jacques.mueller gmx.de> writes:
```On Monday, 12 October 2015 at 20:51:40 UTC, Nordlöw wrote:
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?

Wouldn't it be enough changing the overload

auto iota(E)(E end)

to

auto iota(E)(E end = E.max)

?
```
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
```On 10/12/2015 11:52 PM, Jacques Müller wrote:
On Monday, 12 October 2015 at 20:51:40 UTC, Nordlöw wrote:
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?

Wouldn't it be enough changing the overload

auto iota(E)(E end)

to

auto iota(E)(E end = E.max)

?

No.

import std.range;
writeln(iota(byte.max));

starts at 0
|
v
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55,
56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73,
74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91,
92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107,
108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121,
122, 123, 124, 125, 126]
^
|
ends before 127
```
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
```On 10/12/2015 10:51 PM, Nordlöw wrote:
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?

auto iota(T)(){
import std.range;
return chain(iota(T.min,T.max),only(T.max));
}

void main(){
import std.stdio;
writeln(iota!byte());
writeln(iota!dchar());
}
```
Oct 12 2015
```On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu
wrote:
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

iota!ubyte(0, 256)

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

Nice, that'll also be consistent with uniform!T().
```
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
```On 10/12/2015 11:02 PM, Vladimir Panteleev wrote:
On Monday, 12 October 2015 at 16:34:09 UTC, Andrei Alexandrescu wrote:
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

iota!ubyte(0, 256)

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

Nice, that'll also be consistent with uniform!T().

As will iota!"[]".
```
Oct 12 2015
Timon Gehr <timon.gehr gmx.ch> writes:
```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!"[]" ?
```
Oct 12 2015
John Colvin <john.loughran.colvin gmail.com> writes:
```On Monday, 12 October 2015 at 13:17:32 UTC, Timon Gehr wrote:
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!"[]" ?