[Sbcl-devel] Re: MAYBE-INLINE

[William H. N. <wil...@ai...>]

On Wed, Dec 18, 2002 at 04:51:57PM +0000, Christophe Rhodes wrote:
> Anyone looking at the TODO can't fail to notice that a large amount of
> it regards ANSIfying INLINE and deprecating MAYBE-INLINE.
> 
> However, I can't actually work out in what respect INLINE isn't already
> behaving ANSIly -- disassembly of the various functions in 
>   (declaim (inline foo))
>   (defun foo (x) (1+ x))
>   (declaim (notinline foo))
>   (defun bar (x) (foo x))
>   (defun baz (x) (declare (inline foo)) (foo x))
>   (declaim (inline foo))
>   (defun quux (x) (foo x))
> seemed to me to be what we would expect.
> 
> What's the issue?  What am I missing?

Actually, it may be that this gets taken care of as you say, and that
it's as simple as deleting all the old MAYBE-INLINE (or, as a way of
smoothly deprecating them, making them conditional on a feature
#+SB-DEPRECATED-MAYBE-INLINE-SUPPORT which is in *FEATURES* by default
for some time (6 months?), and a supported build-time option for some
time after that (6 more months?).

I remember being daunted by the whole INLINE issue because of
gotchas like the MACROLET stuff, and making sure to suppress the old
inline definition when you reload a modified file containing
  (declaim (inline frob))
  (defun frob (...)
    (if ...
        (...)
        (frob ...)))
Those things struck me as hard, or at least surprising. But maybe
the MAYBE-INLINE stuff (related only by their association with 
the notion of inlineness) is easy and unsurprising. That'd be pretty
reasonable, actually, since the ANSI behavior is pretty natural
from an implementor's point of view.

-- 
William Harold Newman <wil...@ai...>
still jumping to conclusions after all these years
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C  B9 25 FB EE E0 C3 E5 7C