Here is another example where neither opAssign nor the dtor are called for an assignment (unless a postblit is added too):

---
uint dtorCount;

struct S {
  uint x;
  void opAssign(const ref S rhs) { assert(false, "Not called"); }
  ~this() { ++dtorCount; }
}

void main() {
  S[] a;
  a.length = 1;
  a[0].x = 42; // Some random non-init value

  a[] = S.init;

  assert(a[0].x == 0); // As expected, the value has been reset
  assert(dtorCount == 0); // Passes?!?
}
---


Again, am I missing something obvious here? I can't quite believe that struct lifetime would have been quite as broken for so long.

 – David

On Sunday, 2 August 2015 at 01:50:50 UTC, David Nadlinger wrote:
> Again, am I missing something obvious here? I can't quite believe that struct lifetime would have been quite as broken for so long.

I suspect that what it comes down to is that opAssign doesn't get used all that frequently. Most structs simply don't need it, so code which would hit the bug probably isn't all that common. Obviously, such code exists, but it requires using both opAssign and then putting those structs in arrays - and then catching the resulting bug (which you would hope would happen, but if the difference is subtle enough, it wouldn't necessarily be caught). And if structs with opAssign normally also define a postblit, then it's that much less likely that the problem would be hit.

- Jonathan M Davis

On Sunday, 2 August 2015 at 02:49:03 UTC, Jonathan M Davis wrote:
> On Sunday, 2 August 2015 at 01:50:50 UTC, David Nadlinger wrote:
>> Again, am I missing something obvious here? I can't quite believe that struct lifetime would have been quite as broken for so long.
>
> I suspect that what it comes down to is that opAssign doesn't get used all that frequently. Most structs simply don't need it, so code which would hit the bug probably isn't all that common. Obviously, such code exists, but it requires using both opAssign and then putting those structs in arrays - and then catching the resulting bug (which you would hope would happen, but if the difference is subtle enough, it wouldn't necessarily be caught). And if structs with opAssign normally also define a postblit, then it's that much less likely that the problem would be hit.
>
> - Jonathan M Davis

I couldn't get reference counted types to work as struct members, for some hard-to-track reason, and am actively avoiding it right now as a result. Maybe we've found a cause here? The might be a lot of people like me that gave up trying to track it, and are simply avoiding error-prone uses of structs.

2015-08-02 10:50 GMT+09:00 David Nadlinger via Digitalmars-d < digitalmars-d@puremagic.com>:

>
> Again, am I missing something obvious here? I can't quite believe that struct lifetime would have been quite as broken for so long.


https://issues.dlang.org/show_bug.cgi?id=14860 https://github.com/D-Programming-Language/dmd/pull/4856

Kenji Hara

On Sunday, 2 August 2015 at 03:18:59 UTC, Etienne Cimon wrote:
> On Sunday, 2 August 2015 at 02:49:03 UTC, Jonathan M Davis wrote:
>> On Sunday, 2 August 2015 at 01:50:50 UTC, David Nadlinger wrote:
>>> Again, am I missing something obvious here? I can't quite believe that struct lifetime would have been quite as broken for so long.
>>
>> I suspect that what it comes down to is that opAssign doesn't get used all that frequently. Most structs simply don't need it, so code which would hit the bug probably isn't all that common. Obviously, such code exists, but it requires using both opAssign and then putting those structs in arrays - and then catching the resulting bug (which you would hope would happen, but if the difference is subtle enough, it wouldn't necessarily be caught). And if structs with opAssign normally also define a postblit, then it's that much less likely that the problem would be hit.
>>
>> - Jonathan M Davis
>
> I couldn't get reference counted types to work as struct members, for some hard-to-track reason, and am actively avoiding it right now as a result. Maybe we've found a cause here? The might be a lot of people like me that gave up trying to track it, and are simply avoiding error-prone uses of structs.

Well, another thing to consider is that until very recently, structs that were on the heap didn't have their destructors run. So, there have been way too many holes with regards to this sort of thing and structs. I don't know how many people have stayed away from using structs in error-prone cases like this as opposed to simply had buggy code and not noticed it, but there very well may be quite a few folks out there who have hit this sort of thing and then been very confused about the subtle bugs that resulted, and it's just that no one who noticed figured it out well enough to report it.

- Jonathan M Davis