On Friday, 29 May 2015 at 17:52:58 UTC, Martin Nowak wrote:
On Friday, 29 May 2015 at 13:12:58 UTC, IgorStepanov wrote:
What do you want about this syntax? Maybe you may suggest a
better solution?
The discussion drifts a little OT, if we have opIndexCreate,
then the library AA can be more compatible, but it still won't
be a drop-in replacement.
We went a long way in this direction and if we don't come to the
result yet, that, I think, we haven't thought-out plan.
I suggest you to answer to the following two question:
1. What way to transit to the new AA would be acceptable?
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". However,
aaLiteral attributes hasn't checked by compiler, because it was
used in e2ir. _d_assocarrayliteralTX is not @safe or pure, but aa
can be used in @safe pure code. We may insert additional checks,
see aaLiteral attributes, and raise deprecation message, if
attributes are inacceptable.
If it is the last objection, we may repeat compiler-side part for
the new AA template. Othrewice, lets invent another way.
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.
