RE: `thunk-let'?

[Drew Adams]

> Well, it's in subr-x because I'm not sure that it is yet a good idea to
> "advertize it so loudly" as Stefan uses to say.  Nothing in subr-x is
> described in the manual.

This is not a good approach, IMHO.  Whether we should have
a library that is for "half-baked" stuff is debatable.

But even if it is decided to do that (why?), I don't think
it makes sense to decide whether something gets documented
in the manuals based on how well baked we think it is.
That's a bad criterion to use (IMHO).

And it invites things to fall through the cracks and not
be documented even after they get improved.

The usual criteria for deciding whether something gets
documented in a manual should apply to half-baked
features also.

We should WANT users to try half-baked stuff that we
deliver.  That's how it gets improved.  Not advertizing
something just because it is still iffy is not advisable.

An exception could exist for something that we think
might prove dangerous in some way (e.g. possible data
loss).  But probably something like that should not be
delivered at all - it should just continue to be tested
and improved "internally" until it is not problematic.

If something is TOO iffy then just don't deliver it.
Don't use _doc_ as way of "hiding" something that is
unsure.

My "vote" is to move the stuff in subr.el to where it
belongs, thing by thing, place by place, and to
document any of it that we would normally document,
with no concern about how well baked we might think it is.

> If we are sure that we want to document this right now
> in the manual...

There should be no "right now" based on how finished
something is.  If we really feel that something is
not ready for release then it should just be pulled
from the release.  If something is distributed then
it should be supported normally.

Just one opinion.