Named Arguments in Callable Invocation about onyx-lang HOT 5 CLOSED

I see no problem with the first alternative. Further, I think it's important to be able to designate one or more function parameters that must be keyword-invoked. I suggest # be used in the definition for this purpose:

the-function(a, #b, #c = nil) ->

the-function                -- error, no value for #b
the-function 1, 2           -- error, #b must be assigned by name
the-function 1, #b=2        -- no problem
the-function 1, #b=2, #c=3  -- no problem

I assume a ? suffix on function parameter types is implemented?

the-function(a Int?, #b Int?) ->

the-function        -- a is nil, #b is nil
the-function 1      -- a is 1, #b is nil
the-function #b=2   -- a is nil, #b is 2
the-function 1, 2   -- error, #b must be assigned by name

from onyx-lang.

1. I totally agree on the ability to force named parameters per need - in "very high" safety situations this is a very strong guarantee.

2. Yes, the "maybe-nil-sugar" is a given.

3. Just because param a is Int|Nil doesn't mean you're allowed to omit that arg. If you want it to be nil by default and thereby allow omission, you have to state it the-function(a Int? = nil, #b Int? = nil) -> (assuming the proposed syntax)

from onyx-lang.

1. Awesome.
2. Good.
3. Agreed.

from onyx-lang.

After some months of using, I'm not satisfied with the named-arg syntax. The tag literal is... disturbing. Tags should stick to be values and not double as arg-identifiers - it was a bad call plain and simple!

Number (3) in the issue-OP - same as Crystal, is clearly to prefer.

The colon shaves one space (in "natural lang style syntax"), and one further by ditching the Tag-prefix, thereby also making the arg-name cleaner (primary importance). Two spaces sounds micro-optish, but given 4 args, that's 8 chars, and that's 10% of avail width if sticking to 80 col (which is good still to this day!)

The reason for trying to find an alternative is that : is a control character - it signifies the beginning of an expression-block (python-style). The reason was however moot. Just because you can write unclear code with that doesn't mean we should make all other code unclear (with the "Tag signifies named arg"-syntax).

Example:

foo(x = 47, y = 42, color = 0xffaa00) ->
   say "x = {x}, y = {y}, color = {color}"
   x is 47

-- let's get warmed up

foo 100, color: 0xff0000
foo x: 1, y: 2, color: tmp = 0x00ff00   -- Set a named arg, and assign a variable

-- the following line was the culprit leading to the sorry decision:

if foo x: 47, y: 13: say "looks confusing, but of course it's parseable!"

-- and some better ways of writing it, take your pick:

if foo(x: 47, y: 13) : say "better way of putting it!"

if foo x: 47, y: 13
   say "better way too"

if foo x: 47, y: 13 => say "also better choice"

if foo x: 47, y: 13 then say "actually, anything's better!"

This is already implemented as of today (breaking change).

Important Note

Space after the name: is mandatory!
my-call name: value

If you omit the space - it's a different construct: shorthand-subscript with string as key:

name:value == name["value"]
name:value? == name["value"]?

-- also, as a kind little reminder:
name#value == name[#value]
name#value? == name[#value]?

-- and:
name.1 == name[1]
name.1? == name[1]?

A small price to pay, and a big fat deluxe shorthand notation to gain.

The name:key syntax is up to debate too - and if changed, colon doesn't have to be mandatory - but having a space after the name: is much better style anyway imo.

from onyx-lang.

Personally I don't see the problem with #, but the new way looks alright.

from onyx-lang.