Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Warn when variable is being expanded to function call #3268
Today, Elixir will transform
The downsides is that we add a tiny inconsistency. We can make function call without parens unless it is a function with null-arity. On the other hand, we already have inconsistency in the sense we can only shadow function calls with null-arity by variables. So we are exchanging one by the other.
I have bitten by this issue twice today and I believe a warning to be a far compromise.
referenced this issue
Jul 21, 2015
referenced this issue
Sep 19, 2015
For a historical reference, how it (variable is used as function call) became a problem one more time:
I've got a little collection of thoughts on this subject:
Would this mean you'd have to use parens in pipelines as well? I really like the way pipelines work without parens on 0-arity functions, for example:
my_var |> do_something |> do_something_else |> do_a_third_thing(1, 2)
To suppress this warning, it looks like you'd have to rewrite the above as:
my_var |> do_something() |> do_something_else() |> do_a_third_thing(1, 2)
In this case, the first example makes it obvious that values are being piped to functions (you can't pipe to anything else), and looks a little sweeter in my opinion.
Another thing to think about is the way a human can read Elixir code.
def n do 10 end def random_number do :random.uniform(10) end
Obviously this is a contrived example, but one can think through this code as "I am defining
However, in the case of something like
Lastly, if all functions with 0-arity should be called with parens, wouldn't it make more sense for the preferred style of defining a function to be like this:
def start() do :ok end start()
This would be more consistent than having a definition with one style and a call with another.
Anyway, my main point is that semantically, different styles make more sense in different scenarios. I'm not really sure what the answer is, as I definitely understand what @josevalim is saying (it's thrown me off before too), but those are my two cents
Still +1 to the original issue. I have adopted the following style for function calls long ago:
I suggest everyone else do the same. Even if this issue doesn't make it into Elixir 1.x, it will surely be part of Elixir 2.0. So you have a chance to save yourself some work in the future by adopting a good habit today :)
I see how this could help, but I also prefer keeping parens off zero arty calls. I wonder if instead of warning when parens are missing, the warning would come up when there is a local variable name and a function with zero arity in the same scope.
conn = conn conn = get(conn, ...etc.)
In this case the call to
That may not prevent all the bugs, but might at least prevent some of the more confusing situations?
I am strongly in favour of this warning because it makes Elixir code so much easier to read. Imagine you have this code:
def foo() do # 50 lines of code my_function(something) # ... end
That said, @paulcsmith Elixir's issue tracker is reserved for bugs so maybe we can move this discussion to the Elixir mailing list or to elixirforum?
The call to conn() is never ambiguous. Only "conn". :)