The current ABI describes associative arrays as an opaque type. However, for a debugger to work with them, it must understand the structure. For 2 compilers to be able to generate compatible code, they must agree on the structure. Currently the ABI specifies an AA as an opaque implementation-defined type. This means that multiple compilers will not be able to guarantee compatibility since the AA ABI is not specified. Also, debuggers must refer to the source code of the compiler druntime in order to know how to work with the contents of an AA. Specifying C functions to manipulate the opaque pointer solves the debugger issue, but not the issue of ensuring compatibility across compilers.
The functions are only partly helpful for a debugger. IMHO we should switch completely to using AssociativeArray from object. The current situation of using it only in certain cases is messy.
Being an opaque pointer means that the implementation of associative arrays is entirely up to the runtime, not the compiler. The compiler should emit no dependencies on how it is implemented.
(In reply to comment #2) > Being an opaque pointer means that the implementation of associative arrays is > entirely up to the runtime, not the compiler. The compiler should emit no > dependencies on how it is implemented. To make this work, the compiler has to have a documented interface to the AA. I feel we need a documented set of calls that will be output by the compiler, just as $ is documented as being translated to length. At the moment, the only documentation is "read this file in druntime". It's not a guarantee of how the compiler-AA interface works. Without the guarantee another compiler cannot safely generate compatible code, and debuggers can't be guaranteed to know how to look at the contents of the AA. Am I missing something in this request?
If/when the hashes are replaced with a library implementation there won't be a need to emit any special debugging information, it will largely be automatic. So I think we shouldn't try to add more cruft to the compiler right now.
(In reply to Andrej Mitrovic from comment #4) > If/when the hashes are replaced with a library implementation there won't be > a need to emit any special debugging information, it will largely be > automatic. So I think we shouldn't try to add more cruft to the compiler > right now. Sorry, I meant to the ABI as well.
BTW, I'm currently working on the library AA, but it's more work than anticipated. Mostly because getting all the details of attributes, rvalues, construction and range interfaces right is quite involved. https://github.com/MartinNowak/dmd/tree/libraryAA https://github.com/MartinNowak/druntime/tree/libraryAA
(In reply to Martin Nowak from comment #6) > BTW, I'm currently working on the library AA, but it's more work than > anticipated. Mostly because getting all the details of attributes, rvalues, > construction and range interfaces right is quite involved. > https://github.com/MartinNowak/dmd/tree/libraryAA > https://github.com/MartinNowak/druntime/tree/libraryAA Good luck with it! :>
Wow. Best wishes on that! And yes, being more complicated than anticipated is a familiar feeling w.r.t. AA's. :-)
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dlang.org/issues/4016 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB