IMO the change to mem-aref is bad and will break a lot of code. Until
now the contract of mem-aref was that it received a pointer to an array
of the referenced type and returned a pointer offset into the array.
The fact that it now returns a list is a gratuitous change, with no
utility. If we actually want these semantics(not sure about it), it
should be mem-aptr to implement them
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib
The meaning of mem-aref is that returns the object, not a pointer (unless the array is an array of pointers). It still does that. I'm not sure what you mean by "returns a list" unless it's the conversion of a foreign structure to a plist, which is the default representation of a foreign structure. You can define the appropriate translate method to return any representation of the structure you like, and mem-aref is still completely consistent with the previous meaning, that the object (not a pointer) is returned. We introduced mem-aptr to mean the value of the pointer (not the object) is wanted.
The only danger of breakage is that people previously used bare structure references to mean the pointer (because no other meaning was possible), and wanted the pointer back from mem-aref. That is still supported; if you use the bare structure and mem-aref, you'll get the pointer. If you use (:struct foo), you mean you want the structure, and you'll get it (as a plist or however you defined the translate method). If you want an array of pointers, you can specify (:pointer (:struct foo)) or just :pointer, if you want an array of structures and get a pointer back, you specify (:struct foo) and use mem-aptr.
The current behavior makes sense and is completely compatible with the old. There is no change to mem-aref.
Liam