Closed xsawyerx closed 4 years ago
You could also go the full monty, a la JavaScript:
let foo = `bar ${ baz() + " is awesome"} baby`
where everything inside ${}
(inside backticks) gets run as JS code.
We wouldn't be able to do it with ${}
because that's syntax in Perl for scalars: ${var}
is equivalent to $var
.
This is kind of what we're doing in @{[ ... ]}
though. Raku allows stuff like that though with {}
.
In any case, I don't want to introduce anything else, only to pick what to support and how.
What I was trying to say is, maybe is doesn't make sense to try to restrict what can be done during interpolation. It could be both easier and more useful to just allow any Perl code in there, with whatever syntax you wish, including @{[...]}
. I am not trying to introduce any new syntax.
@{[ ]}
would work if we allow prefix dereferencing and interpolation of dereferencing. Those are two tall orders. We could do it, but maybe at a later phase.
Just saying I wasn't making a call here. Just suggesting that we don't have to support it immediately. (Maybe we can. Maybe we want to talk about it first.)
Closing this. using the following quote by @gonzus which I very much agree with:
[...] maybe is doesn't make sense to try to restrict what can be done during interpolation. It could be both easier and more useful to just allow any Perl code in there, with whatever syntax you wish, including
@{[...]}
. [...]
Interpolated strings can have a lot in them. From an analysis perspective, it would be nice to identify things within them, but to which degree should we support it?
feature postfix_qq
):My general thought is that identifying a single variable or a regular (prefixed) deref is not difficult. That would still require determining #8 to decide whether prefixed deref is supported or not.
${$var} will likely always be more pleasant than
$var->$*`, but it the postfix is likely harder to identify within strings. (Considering I want to enable it for good in future versions, we can still decide to use it.)