Hi, Kotlin 2.4.0 now supports using `[3,1,4]` as a...

# language-proposals

[Norbert Kiesel]

Hi, Kotlin 2.4.0 now supports using [3,1,4] as a shorter alternative for listOf(3, 1, 4). Are there now also plans to support using /num=(\d+)/ as alternative for Regex("""num=(\d+)""")?

[ephemient]

template literals are the generalization in JS:

RegExp`num=(\d+)`

however that probably won't be coming to Kotlin anytime soon https://youtrack.jetbrains.com/issue/KT-52924. a similar proposal in Java has also been partially implemented but run into some design issues

[Norbert Kiesel]

Yeah, but my ask was not for a generic string prefixes, but really using the // syntax as used in Typescript, Perl, PHP, ...
So really would like to be able to use e.g.

const numReg = /num=(\d+)/

instead of

const numReg = Regex("""num=(\d+)""")

Of course, / is already used for other stuff (comments, division), but I do not see a possible case where it would be unclear whether is would be a regex or something else.

Now Typescript e.g. also allows to e.g. use /num=(\d+)/i instead of Regex("""(?i)num=(\d+)"""), but I could see Kotlin using /(?i)num=(\d+)/.

[jw]

By making it easier to create regexes you likely encourage their use without caching

[Ian Botsford]

What do you mean by caching? Compiling the regex only once and reusing it? If so, I'd presume a smart compiler interpreting a regex literal /foo/ would create a backing val inlineRegex = Regex("foo") and use that instead of creating a new Regex every time it's invoked. Presumably it could even go farther and offer some kind of automatic "regex interning" similar to string interning.

[ephemient]

caching is not straightforward - there may be interpolations

[Ian Botsford]

Interpolations in a regex literal? So like /foo${bar}baz/? I don't believe JS/TS allow that. Suppose it's an open question whether the equivalent feature in Kotlin would. 🤷‍♂️ Is interpolation the only/biggest complication for caching?

[ephemient]

I don't know about JS, but Perl and Ruby definitely allow it

[Norbert Kiesel]

also at least personally not something that would affect my coding to avoid caching. I usually always create regex constants if possible, and would of course keep doing that even with this "shorter and more readable code, but no semantic changes" proposal.

[ephemient]

with a hidden complexity like keeping a global table of recently compiled regexes

[Norbert Kiesel]

and yes, I would like to allow /foo${bar}baz/ as well. Of course, should then not be globally cached,

[ephemient]

I don't think that suits kotlin

[Norbert Kiesel]

sorry, what do you mean by "not suits kotlin"?

[Norbert Kiesel]

in my mind, very must aligned with the "use [] instead of listOf" which for me has no semantic changes, but just makes the code a bit more compact.

[Ian Botsford]

I'll concede that the `[]`/`listOf()` case is simpler because there's no expectation of caching or deduplicating. I'd expect val a = [1]; val b = [1] to result in two different arrays/references. Not so with regular expressions.

with a hidden complexity like keeping a global table of recently compiled regexes

The JVM already does string interning, which keeps a global table of recently referenced string constants. Feels pretty similar to me.

[Norbert Kiesel]

Kotlin now I think in 2.4 also handles e.g. "foo".toUpperCase() at compile time. So perhaps if we would limit // to not support string interpolation, could then be handled the same way.