On Friday, 29 May 2015 at 21:58:16 UTC, IgorStepanov wrote:
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
One that doesn't break any code, carefully deprecates necessary
semantic changes, and provides an improved implementation.
You rejects my way (and I could not continue to work in the
winter), and AFAIR you principial objection was: "aaLiteral is
non-@safe for the unsafe code and it is breakage".
The objection was too much code breakage for an inferior
implementation.
https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-66888409
We may insert additional checks, see aaLiteral attributes, and
raise deprecation message, if attributes are inacceptable.
Maybe we can hack around the attribute incompatibilities in the
compiler, we'll have to add deprecations at some point anyhow.
2. What issues disallows us to implement full library AA?
Except .stringof, .mangleof, and other compiler magic.
I see only two issues: opIndexCreate and building aa from
literals.
- error messages
- attributes
- literals (especially polysemous initializers, i.e. ubyte[ubyte]
aa = [0:1, 1:2])
- implicit tail const conversion Val[Key] -> const(Val)[Key]
- lots of magic around making Key const
- delete aa[key]
- lots of other small details (grep for Taarray in
src/expression.c)
This is a heavily used built-in type, we can't risk a rewrite
that breaks lots of code.
