Asking a const-related fix [Was: Re: DMD workforce contribution]

kenji hara k.hara.pg at gmail.com
Mon Nov 7 04:57:28 PST 2011


2011/11/7 bearophile <bearophileHUGS at lycos.com>:
> Given how much often I find this problem in D coding, is someone willing and able to write a patch to allow code like this (it's in Bugzilla, with normal priority)?

The filed issue is here.
http://d.puremagic.com/issues/show_bug.cgi?id=6174

> const struct Foo {
>    const int[5] a;
>    const int[] b;
>    const int[int] aa;
>    this(in int n) pure {
>        this.a[] = n; // line 6
>        this.b = new int[5];
>        this.b[0] = n; // line 8
>        this.aa[1] = 2; // line 9
>    }
> }
> void main() {}
>
>
> The latest DMD gives:
>
> test.d(6): Error: slice this.a[] is not mutable
> test.d(8): Error: this.b[0] isn't mutable
> test.d(9): Error: this.aa[1] isn't mutable
>
> Bye,
> bearophile
>

Only line 6 should be allowed.

Inside constructor, compiler can detect that this.a[n] is part of the
fields of 'this' (because static array is value type), then should
allow to bypass const type checking for assignment.
But dynamic array and associative array are reference type, then
compiler cannot detect that the elements of them (this.b[n] and
this.aa[key]) are part of 'this'. Therefore line 8 and 9 cannot bypass
const type checking, even if inside constructor, then should be
rejected.

I have call this concept "transitively modifiable", and I have
implemented it with dmd/pull/166.
"Transitively modifiable" is only checked inside constructor, and
allow more flexible initializing.
I think this is reasonable improvement.

Kenji Hara.


More information about the Digitalmars-d mailing list