Adding example of calling a function with no args

[jtmoulia]

The preferred method is to include the parens, e.g. f() vs f.

[knewter]

I don't actually prefer f() over f for all of the reasons avdi outlines in his barewords ruby tapas episode, to be honest.

[jtmoulia]

I haven't watched it (paid only), but I think I get where it's heading: you can swap between a variable and a function call transparently? That is pretty cool.

I prefer having the parens so that it is explicit that a function is being called -- perhaps it's not as flexible, but it makes it easier to grok what the code is doing. The clarity is especially useful with Elixir's import/require -- you often have functions in your namespace which aren't in a module's source code file.

[bismark]

Simple example on the "for parens" side: https://github.com/elixir-lang/elixir/blob/master/lib/ex_unit/lib/ex_unit/case.ex#L221

I scratched my head for a while trying to figure out where the binding var was being defined. Only to realized that it was referring to http://elixir-lang.org/docs/stable/elixir/Kernel.html#binding/1.

[nessamurmur]

This is a topic that comes up pretty often: #3

[jtmoulia]

Hey @niftyn8, thanks for the link. Seems like there are a couple of separate questions around using/dropping parens:

• 0 arity function defs
• pipelines
• 0 arity function calls

In the first two cases, I don't care because the parens are noise:

# equivalent function definitions
def func
def func()

# equivalent pipelines
1 |> func2
1 |> func2()

That is not true of the third case:

# not equivalent expressions
thing
thing()

I personally would love for people to default to using parens for 0 arg function calls because it makes references easier to trace for the reader.

It makes sense to not use the parens if you're taking advantage of Elixir's bareword handling (Mixfiles!), or perhaps even aesthetic reasons :) but it should be weighted against the fact that it makes references harder to trace.

I wrote up my thoughts on this in a post.

[whatyouhide]

In Elixir, variables are "very scoped". In a function body, the only variables you can be using are the function arguments and the variables bound in the function body:

foo = :bar

def baz(arg) do
  a = 1
  # Now, only `a` and `arg` are variables in the scope. `foo` is not accessible here
  # (as function bodies get a completely new variable scope).
  this_must_be_a_function
  bindings # this too
end

Since Elixir promotes small and very focused functions, it should be extremely easy to tell if something is a function or a variable since you have to look at a very limited scope to tell if it's indeed a variable.

I'm pretty much in favour of calling function without arguments using no parens, as it makes things prettier and less cluttered:

receive do
  {pid, msg} -> send(pid, {self, msg})
end

[alxndr]

I like to use parens when the function's return value is being saved to a local variable or passed to another function, and elide them otherwise. I think I picked this up from Ruby. In practice, this looks like:

def baz(arg) do
  a = 1
  this_must_be_a_function
  b = this_must_be_a_function()
  c = this_must_be_a_function(b)
  IO.puts a
  IO.puts this_must_be_a_function()
end

[nessamurmur]

I have no real opinions but I want to move the conversation forward to get the PR closed.

I actually kind of like function() but nearly all the Elixir code I've seen has gone the other direction. Personally would be more in favor of going in the direction of no parens because of that.

[whatyouhide]

@niftyn8 I agree! 👍

[jtmoulia]

Heh, I agree that most Elixir code drops the parens -- that's why I opened this ;)

@niftyn8 feel free to close this PR if you decide against it.

[nessamurmur]

Just in the interest of moving forward and keeping PRs clean I'm going to close this since the Elixir community seems to be going the same way as the Ruby community, dropping parens.

Don't mean to be a jerk. If you feel strongly about this feel free to bring it back up down the road.

[jtmoulia]

No problem -- 'community driven' is in the tagline.

[jesenko]

It seems that in future versions of elixir, my_funct() might be preferred to avoid ambiguity with vars (elixir-lang/elixir#3268). Maybe this PR should be merged after all?