On Wednesday, 21 October 2015 at 12:32:37 UTC, Andrei
Alexandrescu wrote:
On 10/21/2015 07:40 AM, Timon Gehr wrote:
On 10/21/2015 12:55 PM, Andrei Alexandrescu wrote:
On 10/19/15 9:49 PM, Jonathan M Davis wrote:
On Monday, 19 October 2015 at 23:37:09 UTC, Timon Gehr wrote:
This is the worst part:
class C{
int[] x=[1,2,3];
}
void main(){
auto mut=new C;
auto imm=new immutable(C);
assert(imm.x[0]==1);
mut.x[0]=2;
assert(imm.x[0]==2);
}
Oooo. Ouch. Yeah, that pushes it from being a good idea to
disallow this
in order to avoid bugs to a necessity to disallow it in
order to avoid
breaking the type system.
Please file, thanks. -- Andrei
(I've filed it in 2013.
https://issues.dlang.org/show_bug.cgi?id=10376 .)
What should be the expected behaviour?
- Don't allow default initialization with mutable indirections
in
aggregates.
- Clone the mutable referenced data for each instance.
- Have different "init" for different mutability.
- ... ?
The quickest way to stop the bleeding is to disallow the code.
It's incorrect for immutable data and misleading for mutable
data. (What an user might expect is that each data comes with a
distinct array.)
I can't believe I didn't know about this huge hole.
Andrei
Fundamentally the problem is that literals of mutable reference
types do not make sense. This is why I argued (before TDPL came
out), that an explicit .dup should be required, rather than
allowing the compiler to secretly add one automatically. Implicit
conversion of an array literal to mutable is ridiculous IMHO.
This is just one manifestation of the problem. It could be quite
difficult to come up with a rule for what should be disallowed.
