wanted: DESTRUCTURING-BIND to signal note on arg-count-error at compile-time

[Tobias C. Rittweiler]

The following does not emit a compiler-note

  (deftype list-of-length (n &optional type)
    (if (zerop n)
        `null
        `(cons ,type (list-of-length ,(1- n)))))

  (declaim (ftype (function (t t) (list-of-length 2)) bar))
  (defun bar (x y)
    (list x y))

  (defun foo ()
    (destructuring-bind (x y z) (bar 1 2)
      (list :x x :y y :z z)))

The reason is lacking compiler-smartness for sb-int:proper-list-of-length-p.

(When fixing this, the changset from 1.0.19.30 may have to be reconsidered.)

[Jan Moringen (scymtym)]

Some initial experiments based on suggestions by pkhuong can be found at https://github.com/scymtym/sbcl/tree/wip-smarter-destructuring-bind.

[Douglas Katzman (dougk)]

These days, destructuring-bind is 10x less slow than it was > 5 years ago. So at least one motivating factor for wanting up-front checking of the shape of input is eliminated.

Any use-case for claiming that you can improve the situation for, say, a structure slot which is known to be a list of three items:
 (destructuring-bind (x y z) (cube-top-left c)
would have required the slot :type sufficiently obfuscated that I presume nobody would write it that way. User code employing types such as (cons t (cons t (cons t null))) seems rare.

Further, given that cons types can't really be analyzed at compile-time due to mutability of conses, it's not likely to be possible to derive anything about input to the destructuring-bind. So unless expressly stated - which people don't do - there's nothing inferenceable.

The only other possible scenario might be (destructuring-bind (x y) (list a b) ...) where the compiler can actually see the LIST constructor, but why would one write such code as that?

Therefore closing as wont-fix, infeasible.