[Issue 11343] [2.064 beta] Error: multiple field initialization

d-bugmail at puremagic.com d-bugmail at puremagic.com
Tue Oct 29 18:51:48 PDT 2013


http://d.puremagic.com/issues/show_bug.cgi?id=11343



--- Comment #8 from Kenji Hara <k.hara.pg at gmail.com> 2013-10-29 18:51:45 PDT ---
(In reply to comment #7)
> To reduce a little the disruption of formerly compilable code is it possible
> and a good idea to make the detector smarter, and allow code like this?
> 
> struct Foo {
>     immutable int[3] arr;
>     this(int x) {
>         arr[0] = x;
>         arr[1] = x + 1;
>         arr[2] = x + 2;
>     }
> }

I think this is difficult if one of the index is given in runtime. For example:

    this(int x, size_t i) {
        arr[0] = x;
        arr[1] = x + 1;
        arr[i] = x + 2;  // which index will be initialized in runtime?
    }

Once arr[i] is used inside constructor, compiler should reject *all other*
initializing of arr (arr[0]=x; and arr[1]=x+1;) to avoid multiple
initialization. I think there's not benefits commensurate with the cost to
implement it. So I won't work for that.

Instead, I'd like to recommend an alternative way how to initialize immutable
int[3] field. Today, NRVO also works for static array data, and you can convert
mutable data to immutable implicitly by using pure *creator* function.

    this(int x) {
        static int[3] make(int x) pure {
            int[3] a;
            a[0] = x;
            a[1] = x + 1;
            a[2] = x + 2;
        }
        this.arr = make(x);  // NRVO works
    }

In near the future, you will be able to use a pure lambda instead of the static
'make' function.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list