Re: Inconsistencies in "-quoting and @-splitting, could someone elaborate?

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Sat, Oct 27, 2018 at 5:34 PM dana <dana@xxxxxxx> wrote:
>
> On 27 Oct 2018, at 05:33, Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx> wrote:
> >I'm having problem in grasping, is this behavior:
> >- "X-flag creates array, unless its result is a single element", and
> >- "X-flag creates array even when double quoted without use of @"
>
> I don't know if it's accurate to say that they 'create an array' — they expand
> to a list of zero, one, or multiple words (or elements, or arguments, or
> whatever you want to call them), which you might then *put into* or (in certain
> parameter-expansion cases) *act on as* an array, but the result of the expansion
> is not an array per se.

You're not wrong, but the documentation consistently refers to a word
list occuring in parameter expansion context as "an array".

To address Sebastian's question, the behavior of (s::) is historical.
Because zsh passes expansions around by value rather than by
reference, in the original implementation of nested expansions a
single-element array value was indistinguishable from a scalar.  This
didn't change until 2015, when extra effort was made to retain the
properties of a parameter across levels of nested expansion.  However,
the result of a split with (s::) is never a parameter (it's just an
array value), so it kept the old behavior.  This is true of anything
that is considered "simple word splitting" (#11 in the "Rules"
subsection of the parameter expansion docs), and also of the (z::)
operation (rule #17).  However, you'll never see the effect unless the
array value is inside a nested expansion; if there is only a single
level of expansion, double-quotes (rule #5) apply before splitting, so
the result remains an array.

To circumvent this historical behavior, the (@) and (A) flags are used
to propagate array interpretation from an inner nesting to an outer
one.