Aaron Sherman wrote:
(updated based on followup conversations)
Proposal: A sigil followed by [...] is always a composer for that type.
%[...] - Hash.
@[...] - Array.
&[...] - Code.
|[...] - Capture. Identical to \(...).
$[...] - Scalar. Like item(...), but forces copying even in argument
lists
Added after:
::[Type:...]
fglock pointed out that @(...), %(...) actually already do this.
I was going to modify this proposal around that, but then I looked at
the variations. I now contend that <sigil>(...) has more of a "cast"
semantic than a "compose" semantic. If we wish to combine the two, then
we could, but that would require that &(...) take a block body, not an
expression (again, not what &(...) does now, at all).
In the end, I still think the bracket forms are a wonderfully simple
solution to the ambiguity problem, and I'm more convinced every time I
look at this that the ambiguity needs a fix. What's more, having one
syntax for composition of container and non-container types in free-form
data structures is tremendously appealing. We've thrown out ${...}, so
we could use that instead of brackets, but that's just one more
shift-key, and it doesn't seem to buy much. Am I wrong?
fglock also suggested that this might not be seen by the community as
"looking like perl." I'm not so sure that's the case, since we already
have @(...) and @{...}, but even if some do feel that way, I AM NOT
proposing that we eliminate any currently correct behavior. I am only
suggesting that we add "one more way to do it" for those of us who want
to dodge the ambiguity. Surely, that's not a big request?
To sum up:
<sigil>(...) - cast expression ... to type implied by sigil
<sigil>[...] - composition of type implied by sigil
Nice and uniform, no?
