function chaining / pipeline oprarator

[chris-kruining]

Intro / Setup / Use case

This a feature in some languages and a feature request for some others. I think that bicep would be a good candidate for this as well.
What I am looking for is -as far as I can see- just syntactical sugar. let's me show with an example with some pseudo code

currently:

var x = c(b(a('some value')))

this would turn into:

var x = 'some value'
|> a()
|> b()
|> c()

This is a suuuuuuuper simple case to illustrate what I am aiming for. this is also not an exact proposal for the actual syntax, I just used what I've seen elsewhere. I am very happy to discuss this topic, I have plenty of ideas.

Speaking of ideas

Here are some:

Implicit defaults

by default the return value of a previous step is passed as the first argument in the next one.

so given a func like this: func some_func(arg1 string, arg2 int, arg3 bool)
it could be called like this: 'some string' |> some_func(10, false)
which the compiler then turns into some_func('some string', 10, false)

Explicit position

What if the returned value of the previous step should not go to the first position?
We could use an implicitly defined variable (in this example _) to mark the position the parameter should go in.

so given a func like this: func some_func(arg1 string, arg2 int, arg3 bool)
it could be called like this: 10 |> some_func('some string', _, false)
which the compiler then turns into some_func('some string', 10, false)

Explicit name

I can imagine that there are cases where you want to be more explicit then using a magically defined variable.
Personally I think I'd use this explicit case when I want to preserve the intention of the argument.
So I reckon that some syntax to "rename" the implicit variable to an explicit name would solve this issue

so given a func like this: func some_func(arg1 string, arg2 int, arg3 bool)
it could be called like this: 10 | a_number > some_func('some string', a_number , false)
which the compiler then turns into some_func('some string', 10, false)

Examples

The small examples above do not really showcase the sugar really well. So I'll add some more complex examples (some which are real world use cases I would like this feature for)

Compose resource properties with multiple functions

type ContainerApp = ... // omitted for brevity 
type Container = ... // omitted for brevity 

func container_app(name string, location string, containers Container[]) ContainerApp => {
    name: name
    location: location
}

func with_managed_identity(app ContainerApp) ContainerApp => 
    union(app, {
        identity: {
            type: 'SystemAssigned'
        }
    })

func with_dapr(app ContainerApp, port int) ContainerApp => 
    union(app, {
        properties: {
            configuration: {
                dapr: {
                    appId: 'some app id'
                    appPort: port
                    enabled: true
                    enabledApiLogging: true
                }
            }
        }
    })

var containerAppConfig = container_app('mycontainerapp', 'west europe', [
    ... // omitted for brevity
])
|> with_managed_identity()
|> with_dapr(3000)

resource myContainerApp 'Microsoft.App/containerApps@2024-03-01' = {
  name: containerAppConfig.name
  location: containerAppConfig.location
  identity: containerAppConfig.identity
  properties: containerAppConfig.properties
}

Consecutive array operations

This use case is always really nice to showcase how a pipeline operator will (imo) improce readability of code. it preserves the order op operations from left to right (or in this case, top to bottom). Whereas normally due to nesting you would need to read from right to left

func double(numbers int[]) int[] => map(numbers, x => x * 2)

var summedValue = [ 1, 2, 3, 4, 5 ]
|> double()
|> filter(x => x > 2)
|> take(3)
|> join(', ')

// summedValue == '4, 6, 8'

Other ideas to empower this operator

Lambda as first class citizen

so that it can be used in user defined code
example. I am not sold on the syntax below, but it does showcase how this would prevent the need for an explicit func definition

var templatedString 'some string'
|> x => 'some template which uses "${x}"'

// templatedString == 'some template which uses "some string"'

combined with "destructuring" / "pattern matching"

destructuring is not a feature, but imagine it is for a moment.
Then we could do the following for example

var KeyValuePair = { key1: 'value1', key2: 'value2', key3: 'value3' }
|> items()
| [ .._, [ key, value ] ] > 'key: ${key}, value: ${value}'

// KeyValuePair == 'key: key3, value: value3'