https://kotlinlang.org logo
Join Slack
Powered by
new in-progress KEEP to improve the handling of `$...
# language-evolution
a
new in-progress KEEP to improve the handling of 
$
and 
"
in (multiline) string literals -> https://github.com/Kotlin/KEEP/issues/375
❤️ 6
k
An interesting read. Thanks. I'm a bit confused by the following phrase on the linked page: "and the double dollar symbol prevents 
$0
and 
$@
to be considered interpolations". Do we really need the double dollar for that? Is there any way "$0" and "$@" can actually be interpolated?
a
mmm, maybe this was not clear... what I meant there is that by adding 
$$
at the beginning, the resulting string will contain the 
$0
as they were written
k
But even with today's existing 
"""
style, the 
$0
and 
$@
would still appear in the resulting string exactly as they were written, wouldn't they?
👌 1
o
Neither 
0
nor 
@
are valid identifiers in Kotlin, so these would not be interpolated. The example in the KEEP looks incorrect.
a
thanks for the catch, let me fix this -> fixed to 
awk '!_[$NAME]++{print}'  """$ARGS"""
👍 2
o
Maybe we could find a more idiomatic example: There is no notion of triple quotes in bash (what we're seeing is 
""
concatenated with 
"$ARGS"
and another 
""
). 
ARGS
is not a predefined variable. The 
awk
expression is somewhat strange. For awk, I'd consider something like this, which prints the last field (login shell) for the user "nobody":
Copy code
awk -F : '/^nobody:/ { print($NF) }' /etc/passwd
For the "triple quote" we'd have to find something where it would actually make sense...
Maybe this one:
Copy code
println($$""""name = "Kotlin"; println("""Hello $name!""")"""")
e
were Groovy's 
$/ /$
slashy strings considered? following similar rules, interpolation would use `$name`/`${expr}` same as other strings, and 
$$
would be a single literal 
$
. IMO that would feel more natural than having to use increasing numbers of `$$`s
a
at the end you can ready a bit about other possibilities which were considered. In this case, we really wanted the ability to embed things like JSON schemas directly in a literal, without any further modification, this is partly why we went with longer interpolation syntax instead of longer escaping of 
$
e
uninterpolated 
'''...'''
would work for that goal too. although then I suppose it becomes a question of, do you want to introduce multiple new types of strings…
3 Views
Open in Slack
PreviousNext
Powered by