SomeType[SomeOtherType] aa;
...
SomeType* aap = aKey in aa;
The lifetime of aap needs to be clarified. In particular with respect to:
* Removal of aKey from the aa
* Removal of another element from the aa
* Addition of another element to the aa
* Modification of an existing element in the aa with "aa[key] = something"
* Modification of this element in the aa with "aa[aKey] = something".
Comment #1 by schveiguy — 2016-11-09T12:31:22Z
IMO:
(In reply to Shachar Shemesh from comment #0)
> The lifetime of aap needs to be clarified. In particular with respect to:
> * Removal of aKey from the aa
This I could go either way. Current code leaves aap as valid. This is what I'd lean towards. This works great if the data is reference counted. Currently, we depend on the GC to collect.
> * Removal of another element from the aa
This should not affect aap.
> * Addition of another element to the aa
No effect.
> * Modification of an existing element in the aa with "aa[key] = something"
No effect.
> * Modification of this element in the aa with "aa[aKey] = something".
Should update data that aap points to.
I would say that these proposed rules invalidate many types of hashing schemes, so we are locked into certain implementation details. But I think that's OK for "good enough" AA implementation. If you want more control, we should have a library type for that.
Comment #2 by shachar — 2016-11-10T06:26:14Z
If there is any doubt re: where AA are going, I think we should take the opposite approach. It is easier to start with "no, this is UB", and the define it than to go the other direction.
Comment #3 by shachar — 2016-11-10T06:27:09Z
Also, we should consider what if SomeType is a class.
Comment #4 by dfj1esp02 — 2016-11-10T10:14:00Z
It's pretty obvious it's a clever low-level hack and relies on internal data layout, which is preserved only by const/inout methods.
Comment #5 by schveiguy — 2016-11-10T13:47:24Z
(In reply to Shachar Shemesh from comment #2)
> If there is any doubt re: where AA are going, I think we should take the
> opposite approach. It is easier to start with "no, this is UB", and the
> define it than to go the other direction.
This doesn't conflict with my recommendations. I think to move to a hash algorithm where rehashing of any kind invalidates AA value pointers obtained from the 'in' operator is going to result in massive breakage. We can't allow that. That is what your points all ask about, except the first. The first can either be "implementation defined" (I prefer this over UB) or valid.
Comment #6 by schveiguy — 2016-11-10T14:06:22Z
(In reply to Shachar Shemesh from comment #3)
> Also, we should consider what if SomeType is a class.
That's irrelevant to this. A pointer to a class instance reference is still a pointer.
Comment #7 by robert.schadek — 2024-12-15T15:23:59Z