Have anybody thought about adding safe enum-based indexing to builtin arrays? Ada has this.

IMHO I believe this could be implemented either in the compiler, druntime or phobos.

Example

    enum I { a=3,b=4,c=5 }
    int[I] x = [3,4,5];
    assert(x[I.a] == 3);
    assert(x[I.b] == 4);
    assert(x[I.c] == 5);

Iteration through

    foreach (i, e; x) {}

where

i is of type I

and

e is of type int

Nordlöw:

> Have anybody thought about adding safe enum-based indexing to builtin arrays? Ada has this.

I'd like this. I'd like even more: a general way to have optionally strongly typed array indexes.


>     enum I { a=3,b=4,c=5 }
>     int[I] x = [3,4,5];

In D currently that "int[I]" is an associative array with I index and int values. So in another post I have suggested another syntax.

Bye,
bearophile

On Saturday, 20 September 2014 at 20:43:28 UTC, bearophile wrote:
> In D currently that "int[I]" is an associative array with I index and int values. So in another post I have suggested another syntax.

Couldn't we simply add an optimization pass that CT-introspects the enumerators of an enum-indexed AA and represent it internally as a lookup-table if the enumerator values are adjacent (enough)?

On Saturday, 20 September 2014 at 21:05:12 UTC, Nordlöw wrote:
> On Saturday, 20 September 2014 at 20:43:28 UTC, bearophile wrote:
>> In D currently that "int[I]" is an associative array with I index and int values. So in another post I have suggested another syntax.
>
> Couldn't we simply add an optimization pass that CT-introspects the enumerators of an enum-indexed AA and represent it internally as a lookup-table if the enumerator values are adjacent (enough)?

Further it would be nice if the newly added std.range.enumerate got support for Enumerator being an enum when instantiated with an enum-indexed array.

Currently it fails, for starters, because the default value of second parameter

    Enumerator start = 0

should be

    Enumerator start = Enumerator.min

in the case when Enumerator is an enum.

Nordlöw:

> should be
>
>     Enumerator start = Enumerator.min

This also requires the enum to have adjacent values (in general enums can skip values).

Bye,
bearophile

On Saturday, 20 September 2014 at 22:00:24 UTC, bearophile wrote:
> Nordlöw:
>
>> should be
>>
>>    Enumerator start = Enumerator.min
>
> This also requires the enum to have adjacent values (in general enums can skip values).
>
> Bye,
> bearophile

Not true, because you can use std.traits.EnumMembers to prepare an enum member rank lookup table, so that values have even not be consecutive.

there is an example here:
http://dlang.org/phobos/std_traits.html#EnumMembers

and a concret application in this personal project (e.g line 111):
https://github.com/BBasile/bitSet/blob/master/import/bitsets/bitsets.d

On Saturday, 20 September 2014 at 22:13:30 UTC, Baz wrote:
> Not true, because you can use std.traits.EnumMembers to prepare an enum member rank lookup table, so that values have even not be consecutive.

You're correct. Even better not having that limitation :)

>
> there is an example here:
> http://dlang.org/phobos/std_traits.html#EnumMembers
>
> and a concret application in this personal project (e.g line 111):
> https://github.com/BBasile/bitSet/blob/master/import/bitsets/bitsets.d

Nice!