'_' as an argument in function definition

[jiang_ming_zhang]

function myfun(x, i, val, _)
x[i]+ = val 
end 

What does the underscore ‘_’ mean here?

[carstenbauer]

I haven’t used it in this context but it usually means “I don’t need to give this argument a name because I’m not going to use it”. More common is

for _ in 1:10
    println("I don't care about the iteration variable here")
end

[lrnv]

This is the right interpretation, but it is a bit more powerful than just saying you won’t use it: you cannot use this variable, so the compiler can take this fact into account and optimize accordingly.

[carstenbauer]

Do you have a source (or good example) for this? I would think that the compiler can equally optimize if I’m not using a named function argument. Would be surprising to me if that was only the case for _.

[lrnv]

Well no, I was assuming that from the behavior of the compiler on other similar issues. I think you might be able to show that on the right example, but you are right I have no proof.

[abraemer]

See for example this thread:

Usage rules for bare underscores

I’ve seen a few examples where one can use a bare underscore in an expression, e.g., julia> map(_ -> "hello", 1:4) 4-element Array{String,1}: "hello" "hello" "hello" "hello" julia> ["hello" for _ in 1:4] 4-element Array{String,1}: "hello" "hello" "hello" "hello" julia> for _ in 1:4 println("hello") end hello hello hello hello But of course the following doesn’t work: julia> _ = 2 2 julia> _ ERROR: all-underscore identifier used as rvalue However, I haven’t seen a…

The key terminology is that _ cannot be used as an rvalue, which roughly means it cannot appear on the right hand-side of an assignment (or any other expression that is not an explicit assignment).

[carstenbauer]

Let’s be a bit more precise here. The statement I’m questioning is this:

@lrnv

it is a bit more powerful than just saying you won’t use it: you cannot use this variable, so the compiler can take this fact into account and optimize accordingly.

This suggests - at least to me - that, compared to a regular (unused) function argument, _ is somehow special in that it gives extra “you cannot use it” guarantees to the compiler. And if this is what is meant here, I tend to disagree and would like to see an example showing this different optimization potential. To be clear, I would claim that the optimization for _ (cannot be used) and a regular unused function argument (won’t be used) is just the same.

I don’t see how the thread you’ve linked gives any more insights into this comparison. The only “new” thing it points out is that you can’t use _ in conjuction with keyword arguments (which is clearly a difference to a regular argument). However, this is a bug and also doesn’t say anything about optimization potential.

But perhaps I’m just misunderstanding the statement in the first place?

[GunnarFarneback]

I’m also skeptical that it would make a difference for optimization but it’s correct that it cannot be used and thus gives the reader of the code a guarantee that it won’t have any effect.

@abraemer

The key terminology is that _ cannot be used as an rvalue

For information this terminology is on its way out and will be changed in Julia 1.11: Call all-underscore identifiers write-only by GunnarFarneback · Pull Request #50830 · JuliaLang/julia · GitHub

[lrnv]

@carstenbauer

This suggests - at least to me - that, compared to a regular (unused) function argument, _ is somehow special in that it gives extra “you cannot use it” guarantees to the compiler. And if this is what is meant here, I tend to disagree and would like to see an example showing this different optimization potential. To be clear, I would claim that the optimization for _ (cannot be used) and a regular unused function argument (won’t be used) is just the same.

I don’t see how the thread you’ve linked gives any more insights into this comparison. The only “new” thing it points out is that you can’t use _ in conjuction with keyword arguments (which is clearly a difference to a regular argument). However, this is a bug and also doesn’t say anything about optimization potential.

But perhaps I’m just misunderstanding the statement in the first place?

1° You understood what I meant correctly.

2° I tried but was not able to make an example. You are right the claim was a bit too bold.

I thought that the compiler would use the information that _ cannot escape, but i was not able to find a good example. I appologize.