[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