> Zen slicing as a possible way of 'de-containerizing' :
> https://docs.raku.org/language/subscripts#index-entry-Zen_slices

A zen-slice only affects the single reference it's applied to.

And it is a no op when applied to anything other than a `Scalar`.

So it'll have no effect when applied directly to an array, list, hash,
or other non `Scalar`.

Perhaps you're thinking "decontainerizing" does something other
than what it does? It's really a very simple operation. An analogy
is having a bunch of folk, some of whom always go by their legal
name, but others who sometimes go by their nickname. And let's
say there's an operation called "use legal name". When applied
to a nickname it yields the corresponding legal name. But when
applied to a legal name it just yields that name, i.e. it's a no op.

That's all that decont does, except the analog to a nickname is
a `Scalar`, and the analog to a legal name is anything else.

> Even if the ",=" postfix operator were to gain this ability on non-hash
> objects, then hash-objects would be special-cased in **not** requiring
> a Zen-sliced decontainerized object on the LHS, so people would have
> to consider that outcome.

I think the focus on `,=`.is really unfortunate, because the real issue is
just about what `=` does with a non-`Scalar` on its LHS and a list of
values on its RHS. It's really got nothing whatsoever to do with `,`.

It just depends on the type of non-`Scalar` on the LHS of `=`.

Look what happens without not a comma in sight:

my %hash = do for ^1 { %hash }
say %hash; # {}

If it's a hash,, the only sensible thing to do with a list of values that may
each be a pair, or a list of pairs, or an array of pairs, or a hash of pairs,
is to flatten and concatenate all the individual pairs into the hash.

my @array = do for ^1 { @array }
say @array; # (\Array_73652568 = [Array_73652568])

But if it's an array, the sensible thing to do is to *not* flatten by default.

Reply via email to