156 lines
4.9 KiB
Markdown
156 lines
4.9 KiB
Markdown
# Declaring arguments in Lyng
|
|
|
|
It is a common thing that occurs in many places in Lyng, function declarations,
|
|
lambdas and class declarations.
|
|
|
|
## Regular
|
|
|
|
## Default values
|
|
|
|
Default parameters should not be mixed with mandatory ones:
|
|
|
|
// ok:
|
|
fun validFun(a, b, c=0, d=1) {}
|
|
|
|
// this is a compilration error
|
|
fun invalidFun(a, b=1, c) {} // throw error
|
|
|
|
Valid examples:
|
|
|
|
fun foo(bar, baz="buz", end= -1) {
|
|
println(bar + ' ' + baz + ' ' + end)
|
|
}
|
|
foo("bar")
|
|
foo("nobar", "buzz")
|
|
foo("nobar", "buzz", 120)
|
|
>>> bar buz -1
|
|
>>> nobar buzz -1
|
|
>>> nobar buzz 120
|
|
>>> void
|
|
|
|
# Ellipsis
|
|
|
|
Ellipsis are used to declare variadic arguments. It basically means "all the arguments available here". It means, ellipsis argument could be in any part of the list, being, end or middle, but there could be only one ellipsis argument and it must not have default value, its default value is always `[]`, en empty list.
|
|
|
|
Ellipsis argument receives what is left from arguments after processing regular one that could be before or after.
|
|
|
|
Ellipsis could be a first argument:
|
|
|
|
fun testCountArgs(data...,size) {
|
|
assert(size is Int)
|
|
assertEquals(size, data.size)
|
|
}
|
|
testCountArgs( 1, 2, "three", 3)
|
|
>>> void
|
|
|
|
Ellipsis could also be a last one:
|
|
|
|
fun testCountArgs(size, data...) {
|
|
assert(size is Int)
|
|
assertEquals(size, data.size)
|
|
}
|
|
testCountArgs( 3, 10, 2, "three")
|
|
>>> void
|
|
|
|
Or in the middle:
|
|
|
|
fun testCountArgs(size, data..., textToReturn) {
|
|
assert(size is Int)
|
|
assertEquals(size, data.size)
|
|
textToReturn
|
|
}
|
|
testCountArgs( 3, 10, 2, "three", "All OK")
|
|
>>> "All OK"
|
|
|
|
## Destructuring with splats
|
|
|
|
When combined with splat arguments discussed in the [tutorial] it could be used to effectively
|
|
destructuring arrays when calling functions and lambdas:
|
|
|
|
fun getFirstAndLast(first, args..., last) {
|
|
[ first, last ]
|
|
}
|
|
getFirstAndLast( ...(1..10) ) // see "splats" section below
|
|
>>> [1,10]
|
|
|
|
# Splats
|
|
|
|
Ellipsis allows to convert argument lists to lists. The inversa algorithm that converts [List],
|
|
or whatever implementing [Iterable], is called _splats_. Here is how we use it:
|
|
|
|
fun testSplat(data...) {
|
|
println(data)
|
|
}
|
|
val array = [1,2,3]
|
|
testSplat("start", ...array, "end")
|
|
>>> [start,1,2,3,end]
|
|
>>> void
|
|
|
|
There could be any number of splats at any positions. You can splat any other [Iterable] type:
|
|
|
|
fun testSplat(data...) {
|
|
println(data)
|
|
}
|
|
val range = 1..3
|
|
testSplat("start", ...range, "end")
|
|
>>> [start,1,2,3,end]
|
|
>>> void
|
|
|
|
## Named arguments in calls
|
|
|
|
Lyng supports named arguments at call sites using colon syntax `name: value`:
|
|
|
|
```lyng
|
|
fun test(a="foo", b="bar", c="bazz") { [a, b, c] }
|
|
|
|
assertEquals(["foo", "b", "bazz"], test(b: "b"))
|
|
assertEquals(["a", "bar", "c"], test("a", c: "c"))
|
|
```
|
|
|
|
Rules:
|
|
|
|
- Named arguments must follow positional arguments. After the first named argument, no positional arguments may appear inside the parentheses.
|
|
- The only exception is the syntactic trailing block after the call: `f(args) { ... }`. This block is outside the parentheses and is handled specially (see below).
|
|
- A named argument cannot reassign a parameter already set positionally.
|
|
- If the last parameter has already been assigned by a named argument (or named splat), a trailing block is not allowed and results in an error.
|
|
|
|
Why `:` and not `=` at call sites? In Lyng, `=` is an expression (assignment), so we use `:` to avoid ambiguity. Declarations continue to use `:` for types, while call sites use `as` / `as?` for type operations.
|
|
|
|
## Named splats (map splats)
|
|
|
|
Splat (`...`) of a Map provides named arguments to the call. Only string keys are allowed:
|
|
|
|
```lyng
|
|
fun test(a="a", b="b", c="c", d="d") { [a, b, c, d] }
|
|
val r = test("A?", ...Map("d" => "D!", "b" => "B!"))
|
|
assertEquals(["A?","B!","c","D!"], r)
|
|
```
|
|
|
|
The same with a map literal is often more concise. Define the literal, then splat the variable:
|
|
|
|
fun test(a="a", b="b", c="c", d="d") { [a, b, c, d] }
|
|
val patch = { d: "D!", b: "B!" }
|
|
val r = test("A?", ...patch)
|
|
assertEquals(["A?","B!","c","D!"], r)
|
|
>>> void
|
|
|
|
Constraints:
|
|
|
|
- Map splat keys must be strings; otherwise, a clean error is thrown.
|
|
- Named splats cannot duplicate parameters already assigned (by positional or named arguments).
|
|
- Named splats must follow all positional arguments and positional splats.
|
|
- Ellipsis parameters (variadic) remain positional-only and cannot be assigned by name.
|
|
|
|
## Trailing-lambda rule interaction
|
|
|
|
If a call is immediately followed by a block `{ ... }`, it is treated as an extra last argument and bound to the last parameter. However, if the last parameter is already assigned by a named argument or a named splat, using a trailing block is an error:
|
|
|
|
```lyng
|
|
fun f(x, onDone) { onDone(x) }
|
|
f(x: 1) { 42 } // ERROR
|
|
f(1) { 42 } // OK
|
|
```
|
|
|
|
|
|
[tutorial]: tutorial.md
|