Re: scope Sergei Egorov (20 Oct 2025 17:08 UTC)
Re: scope / order Sergei Egorov (20 Oct 2025 17:34 UTC)
Re: scope / order Daphne Preston-Kendal (25 Oct 2025 10:55 UTC)
Re: scope / order Marc Nieper-Wißkirchen (25 Oct 2025 11:36 UTC)
Re: scope / order Sergei Egorov (25 Oct 2025 15:05 UTC)
Re: scope / order Arthur A. Gleckler (25 Oct 2025 18:30 UTC)
Re: scope / order Daphne Preston-Kendal (26 Oct 2025 21:56 UTC)
Re: scope / order Daphne Preston-Kendal (26 Oct 2025 22:22 UTC)
Re: scope / order Sergei Egorov (26 Oct 2025 23:49 UTC)
Re: scope / order Arthur A. Gleckler (27 Oct 2025 00:05 UTC)
Re: scope / order Sergei Egorov (27 Oct 2025 00:11 UTC)
Re: scope / order Marc Nieper-Wißkirchen (27 Oct 2025 09:22 UTC)
Re: scope / order Daphne Preston-Kendal (27 Oct 2025 09:42 UTC)
Re: scope / order Marc Nieper-Wißkirchen (27 Oct 2025 10:14 UTC)
Re: scope / order Sergei Egorov (27 Oct 2025 16:46 UTC)
Re: scope / order Daphne Preston-Kendal (26 Nov 2025 23:00 UTC)
Re: scope / order Sergei Egorov (27 Nov 2025 01:14 UTC)
Re: scope Daphne Preston-Kendal (20 Oct 2025 18:48 UTC)
Re: scope Sergei Egorov (20 Oct 2025 20:40 UTC)
Re: scope Wolfgang Corcoran-Mathe (20 Oct 2025 21:56 UTC)

Re: scope Wolfgang Corcoran-Mathe 20 Oct 2025 21:56 UTC

On 2025-10-20 17:08 +0000, Sergei Egorov wrote:
> > I second (third?) Daphne & Marc here. If the matching order is
> > unspecified, then ban variable references that depend on order.
>
> They are banned already, that was the intent from day 0 (if you are
> talking about pattern var references).

Understood.  But in that case, it's very confusing that the sample
implementation allows such references.  I know that providing a
"non-portable extension" is one possibility for cases of UB, but an
extension that creates surprising intra-pattern bindings seems like
a bad idea, in principle.  I would much prefer that the implementation
signal an error.

--
Wolfgang Corcoran-Mathe  <xxxxxx@sigwinch.xyz>