bug#59576: 29.0.50; named-let doesn't support dynamic binding

[Tom Levy]

Personally I'm fine with `named-let' signalling an error in dynamic
binding mode.

(Regarding worse code in lexical binding mode: There are workarounds.
An ugly one is to include both versions of `named-let' and switch
between them depending on the binding mode. Another solution is to
teach the byte-compiler to inline funcalls to let-bound lambdas;
that's more elegant and might also benefit other code, but I have no
idea how difficult it would be to implement.)

On Sat, 26 Nov 2022 at 22:49, Mattias Engdegård <mattiase@acm.org> wrote:
>
> `named-let` being a looping construct, it makes little sense to use it in 
> dynamic binding where TCO opportunities are severely limited. Ideally we 
> should just signal an error if an attempt to use it in dynbound code is made. 
> Users will thank us for that (at least they should, if they have any sense).
>
> Second-best would be to inhibit all TCO in dynbound code but whom would that 
> really benefit?
>
> (Regarding your proposal, generating worse code in lexbind mode isn't a 
> wonderful outcome.)
>