Clear questions and runnable code
get the best and fastest answer
If we begin by taking my out of the equation, and simplify by using an array rather than a hash, it’s easy to see the difference:
Whereas \@... evaluates as a reference to a variable, \(...) evaluates as a reference to the final value (a scalar) of the list within the parentheses.
Does the same logic hold when my is reintroduced? It would appear so:
Assigning to @c affects the contents of @$q, showing that \my @c not only declares @c as a lexical variable but also returns a reference to it. But \my(@c) declares @c as a lexical variable and then returns its contents as an empty list, with the result that the expression returns a reference to undef.
Now to Deparse: The problem is not that it fails to distinguish between the two cases, since it clearly does: \my(%hash) and \(my(%hash)) are not the same. The problem becomes apparent if we add some labels:
Deparse changes (a) into (b) but also changes (b) into (c). That is, running Deparse on its own output will produce a different result the second time around: (a) --> (b) --> (c). This certainly looks like a bug.
The use of warn introduces another anomaly. Consider:
In the OP’s code, warn appears to be treating \my(%hash) as undef, and not as \undef, as would be expected. I don’t see the reason for this, either.
Update: Thanks to tye for clearing up the behaviour of warn:
Constructing a reference to each scalar in an empty list gives one an empty list of references, which is just an empty list.
I had to read this several times before the lightbulb went on. Of course! There is no undef, only an empty list. I’d forgotten about context — the key point being, as tye says, that \( ... ) returns a list of references.
Athanasius <°(((>< contra mundum