https://issues.dlang.org/show_bug.cgi?id=16674

Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com

--- Comment #1 from Steven Schveighoffer <schveiguy@yahoo.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=16674

--- Comment #2 from Shachar Shemesh <shachar@shemesh.biz> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=16674

--- Comment #3 from Shachar Shemesh <shachar@shemesh.biz> ---
Also, we should consider what if SomeType is a class.

--

https://issues.dlang.org/show_bug.cgi?id=16674

--- Comment #4 from anonymous4 <dfj1esp02@sneakemail.com> ---
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.

--

https://issues.dlang.org/show_bug.cgi?id=16674

--- Comment #5 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=16674

--- Comment #6 from Steven Schveighoffer <schveiguy@yahoo.com> ---
(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.

--

https://issues.dlang.org/show_bug.cgi?id=16674

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec

--

https://issues.dlang.org/show_bug.cgi?id=16674

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3

--

https://issues.dlang.org/show_bug.cgi?id=16674

--- Comment #7 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/dlang.org/issues/4063

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--