-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Named Arguments in Callable Invocation #16
Comments
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
I assume a
|
|
|
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 Example:
This is already implemented as of today (breaking change). Important NoteSpace after the If you omit the space - it's a different construct: shorthand-subscript with string as key:
A small price to pay, and a big fat deluxe shorthand notation to gain. The |
Personally I don't see the problem with |
Named Arguments in Callable Invocation
Alternatives
1: Current: Use Tag-literal to denote arg-name assignment.
foo #named-arg = 47, #other-arg = "Ok!"
, same with parenthesis:foo(#named-arg = 47, #other-arg = "Ok!")
Shining light on the complications requiring some thought as to syntax:
2: Use
=
with the names without Tag-literal notation, require a more explicit notation for assigning variables in the contexts of args of calls, say:=
. This would not be a "first assign" designator - just means: "assign is actually intended in this context". In the case of when "explicit first assigns" is demanded, it could perhaps double for that role in these contexts - so that you don't have to whip out something likemy-call(and-assign ':= 47)
.For this case, the assignment syntax should also apply to control structures like
if
, which also would make things a bit clearer (especially since it's a common pattern in Onyx because of Nil-elimination branching.3: Use colons, like in map notation. This however clashes with "python-style" nesting control symbol
:
. So, requires a core syntax overhaul:if some-foo x: 13, y: 56, verify: true then do-shit
. Thethen
here could have been a:
which mess things up, unless using parentheses call, which would be an inconsistent requirement.The text was updated successfully, but these errors were encountered: