A modern programming language that makes developers happier.

kotlinlang

(I’m starting a new thread so I can continue learning &amp; asking about the `expr {}` syntax)

&gt; I’m not a fan of the `expr {}` syntax to access the variables. I think they should be accessible directly, which makes the code look more Kotlinesque and helps with auto-complete discovery.
&gt; 
&gt; I expected to be able to use the variables directly, so I first tried `"kotlin-konan-${runner.os}"`, which failed.
&gt; 
&gt; I wasn’t able to find anything close using auto-complete, so I tried using `"kotlin-konan-\${{runner.os}}"`, which seemed to work but of course it’s not the ‘proper’ way. I had to look it up `expr {}` in the docs.

&gt; ```&gt; expr { "${github.repository_owner} == 'typesafegithub' || ${github.event_name} != 'schedule'" }
&gt; &gt; ```
&gt; ^^ here is an example of why accessing directly the variables wouldn’t work, there would be multiple `${{ }}` instead of just one.
&gt; The expression makes only sense… inside an expression bloc.
&gt; That’s what `expr { }` is modelling
&gt; 
&gt; <@U0B8UKF8R> <https://kotlinlang.slack.com/archives/C02UUATR7RC/p1685520581717289?thread_ts=1685519816.431979&amp;cid=C02UUATR7RC>
hey :wave:

I understand that the output is different, but I didn’t know there was a problem with having multiple `${{}}`. I can see <https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#example-of-run-name|some examples> in the docs that have multiple

```run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}```

if I hack around then I can write this condition:

```condition = "${github.repository_owner} == 'typesafegithub' || ${github.event_name} != 'schedule'",```
which to me is more readable, but what’s I’m more focusing on is that it’s more discoverable. I can use autocomplete to get the variables, while `expr {}` hides the variables and has no visible KDoc (<https://youtrack.jetbrains.com/issue/KTIJ-25195/|because of an IJ bug?/feature?>) so (as a new user) I have no idea that it’s supposed to be used. It’s awkward that I have to look up the details in the docs

build.main.kts.kt

<@U01681FLZC2> maybe not what you are looking for, but once the *yaml2kotlin* converter is ready, that will improve readability because the expressions in your existing workflows will be converted to use `expr { }`
<https://github.com/typesafegithub/yaml2kotlin>

when it comes to improving discoverability/comprehension any idea that involves opening a website is disqualified :stuck_out_tongue_winking_eye:

what? I would say it’s much easier to convert your existing YAML workflow by using a webtool with copy/paste + button, than learning the library from scratch

sorry, I’m teasing, which doesn’t come across well in text :bow:

no issue, doing that often as well :slightly_smiling_face:

Regarding missing docs, that is one of the three big caveats, the other two are related to `@file:Import` usage.

The missing docs is the same why you cannot navigate to the source though the source archive would be available.

The issue to track is <https://youtrack.jetbrains.com/issue/KTIJ-16532> and to mitigate it, just add the library to your production dependencies as long as you are editing the workflow scripts, then navigation to source and documentation work properly.