Not sure if it's a bug or not : (DMD 2.010)

class Food{}
const(int[Food]) caa;
const(Food) x = new Food;
x in caa;

Error: cannot implicitly convert expression (x) of type const(Food) to test.Food

Shouldn't x be a const parameter, as it's not going to be modified by the in operator as far as I know ?

On 15/02/2008, funog <funog@ifrance.com> wrote:
>  const(int[Food]) caa;

Why would you want an associative array that you can't modify? I would have thought

    int[const(Food)] caa;

would be a more useful declaration.

But you may well be right that this is a bug. Const correctness hasn't
completely permeated though D yet. Even opEquals() and opCmp() are
still declared as

    int opEquals(Object o)

instead of the const-correct

   const int opEquals(const(Object) o)

So it wouldn't surprise me if opIn() and opIn_r() are also not const correct.

I would like to think that Walter (...when he can find time...) will soon go through all of the operator overloads and make sure that every single one of them is const-correct in D2, and that override catches everything that doesn't follow suit, and that built-in types like AAs follow const-correct behavior.

Janice Caron Wrote:

> On 15/02/2008, funog <funog@ifrance.com> wrote:
> >  const(int[Food]) caa;
> 
> Why would you want an associative array that you can't modify?

If it is passed to a function as read-only

void foo(const(int[Food]) readOnlyAArray) { ... }