Raymond Toy <[EMAIL PROTECTED]> writes: >>>>>> "Christoph" == Christoph Breitkopf <[EMAIL PROTECTED]> writes: > > Christoph> Hello, > > Christoph> I have a problem that the return type from aref does > Christoph> not agree with the declared element type of the array. > Christoph> Here is a short test program: > > Christoph> (declaim (optimize (speed 2) (safety 2) > Christoph> (extensions:inhibit-warnings 0))) > > Christoph> (defun elem-length (x i) > Christoph> (declare (type (simple-array simple-base-string 1) x)) > Christoph> (let ((s (aref x i))) > Christoph> ; (declare (type simple-base-string s)) > Christoph> (length s))) >[...] > Christoph> Why does the compiler infer (OR NULL VECTOR CONS) for (aref x i)? > > I think this happens because CMUCL doesn't have a specialized array > type for arrays with simple-base-string. Thus, the actual type of the > array is (simple-array T 1). Compare with what > upgraded-array-element-type says for simple-base-string. > > Earlier versions would trust your declared element-type, but later > versions took this out as being unsafe because the compiler and > runtime couldn't really prove it was true. For example, you could > call elem-length with any 1D simple-array and bad things could happen > if it wasn't really a (simple-array simple-base-string 1).
Is that behavior dependent on the safety/speed settings? I know Python tries to do lots of type inference itself, but isn't the point of declarations to tell the compiler things that it might not be able to figure out on its own? I.e., if I change the above to optimize (speed 3) (safety 0), why shouldn't the compiler believe me? (I've tried it with 18e, and it gives the same warnings.) -- Todd Sabin <[EMAIL PROTECTED]>
