Comment 2 for bug 2019125

Hi Martin,

The cited definition of "expressly adjustable" contains the important line: "All arrays that are expressly adjustable are actually adjustable, but not necessarily vice versa." So it's permissible that some actually adjustable arrays are not expressly adjustable.

I believe that on SBCL all vectors with fill pointers and all displaced arrays are actually adjustable, even those that are not expressly adjustable, but in principle some other implementation might offer non-adjustable vectors with fill pointers or displaced arrays. So it's potentially a portability pitfall for a program written on SBCL to depend on the actual adjustable-ness of vectors with fill pointers or displaced arrays.

(Background: the underspecified distinction between actual vs. expressly adjustable traces back to CLtL1, and derives from a disagreement between the Lisp Machine people and the "stock hardware" people circa 1982. On the MIT-derived Lisp Machines (at least the ones around when CLtL1 was being drafted), all arrays were actually adjustable, and the LispM camp pushed for adjustable arrays in Common Lisp, for whatever reasons. The non-LispM camp mostly didn't want adjustable arrays, but compromised and included them, provided that the language included declaration types that might describe and constructor syntax that might produce not-actually-adjustable arrays at the implementation's discretion. So that's what we ended up with.)