Bug 8638 – built-in array opSliceAssign fails with user defined opAssign

Status
NEW
Severity
enhancement
Priority
P4
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-09-10T06:35:34Z
Last change time
2024-12-13T18:01:18Z
Assigned to
No Owner
Creator
monarchdodra
Moved to GitHub: dmd#18467 →

Comments

Comment #0 by monarchdodra — 2012-09-10T06:35:34Z
In a word: -------- struct S { void opAssign(int j); } void main() { int[] i; i[] = 5; //Here1 S[] s; s[] = 5; //Here2 } -------- Actual behavior: Here2: Error: cannot implicitly convert expression (5) of type int to S[] Expected behavior: Here2: opAssign(5) is called for each member of s, just like for Here1. Ditto for all other flavors of opSliceSomething.
Comment #1 by monarchdodra — 2012-09-12T01:47:03Z
The issue can be worked around as such: -------- struct S { int i; void opAssign(S); void opAssign(int j); } void main() { ulong[] i; i[] = cast(ushort)5; //Here1 S[] s; s[] = S(5); //Here2 } -------- However, this shifts the requirement: *from isAssignable!(S,V) *to isAssignable!(S,S) && "canBeConstructedFrom!(S, V)" Where S is the user defined struct, and V is another type. Note that the built-in opSliceAssign DOES support assignement of V to S (HERE1), so there is indeed a limitation/bug/ER.
Comment #2 by monarchdodra — 2012-09-16T14:14:17Z
Just wanted to document that the issue also exists for opOpAssign: -------- struct S { void opOpAssign(int); } void main() { S[] ss; ss[]+=1; } -------- Also, I'm not 100% sure if this is a bug or not, but I believe it *should* work, so I'm re-labeling as ER
Comment #3 by robert.schadek — 2024-12-13T18:01:18Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18467 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB