Skip to content

Document function argument evaluation order #24603

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.

Sign up for GitHub

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

Closed
wants to merge 4 commits into from
Closed

Document function argument evaluation order #24603

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
1306483
Document function argument evaluation order
yurivish Nov 14, 2017
a8273db
fix wording
yurivish Nov 14, 2017
96d42cd
Update functions.md
yurivish Nov 14, 2017
370f97c
;->,
yurivish Nov 14, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 16 additions & 0 deletions doc/src/manual/functions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -328,6 +328,22 @@ Notice the extra set of parentheses in the definition of `range`.
Without those, `range` would be a two-argument function, and this example would
not work.

## Argument evaluation order

All arguments passed to a function are evaluated in lexical left-to-right order.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be nice to show an example with keyword arguments as well. (#23104 was where this changed IIRC.)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This example is also very slightly misleading --- the reason d default gets printed after is that it actually happens in a subsequent method call. Due to the way optional arguments work, that will also always be lexically later, but it's technically a different reason.

Copy link
Contributor Author

@yurivish yurivish Nov 21, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. I tried to pare this example down from a more complicated one with even more subtle behavior involving specifying keyword arguments out of order...

Is it fair to say that the rules can be summarized as: first evaluate all passed arguments from left to right wrt. the order at the call site, and then evaluate all default values from left to right wrt. the order in the method definition, with all defaults being evaluated in a separate method call due to the mechanics of default arguments?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's right. Really, every case is intuitive except maybe f(a, b=1, c, d=2, ...) where keyword and positional arguments are mixed.

Copy link
Contributor Author

@yurivish yurivish Nov 22, 2017 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unrelatedly, I wonder if we should call them "named arguments" for consistency with named tuples. There's precedent for that nomenclature, though both Python and Ruby opt for "keyword argument" instead.

https://en.wikipedia.org/wiki/Named_parameter


```jldoctest
julia> f(a, b, c, d=println("d default")) = a
f (generic function with 1 method)

julia> f(println("a"), println("b"), println("c"))
a
b
c
d default

```

## Varargs Functions

It is often convenient to be able to write functions taking an arbitrary number of arguments.
Expand Down