Emit warning when variable is being expanded to function call

[lexmag]

Closes #3268.

[josevalim]

I think the goal is to warn only if inside a function, i.e. E#elixir_env.function is not nil.

[josevalim]

We need to add to the error message: ", please use parentheses to remove the ambiguity and solve this warning"

[josevalim]

@lexmag just a heads up: let's move this to 1.3. There are already quite some changes in 1.1 and 1.2 is meant to be completely compatible. So 1.3 is when we can start pushing this.

[lexmag]

I'm still wondering if it'll be considered inconsistent if we emit this warning only inside functions.

[josevalim]

What do you mean by only inside functions? We should always emit it,
regardless of __ENV__.function is nil or not, no?

[lexmag]

Yes, but previously (Jul 21, 2015) we thought "to warn only if inside a function".

The only downside of not checking if "function isn't nil" is the following:

[josevalim]

[danhper]

When compiling a project using the master branch, I found out this warning, which I think is good in almost all cases.
However, I am a little concerned about DSLs.
For example, to define an Ecto schema, this forces to write:

  schema "my_schema" do
    field :my_field, :string

    timestamps()
  end

which I think does not look very DSL like.
So basically I think this change would remove the syntax-sugar for all booleans attributes in DSLs.

I did not look at the implementation details yet, but do you think it would be possible and worth to handle such a case?

[whatyouhide]

@tuvistavie timestamps in the DLS you showed presents the same problem that this warning is trying to solve: if you have timestamps = :foo a few lines up, it will override your timestamp function (macro) call. Personally I don't think it's worth to handle such a case (provided it is possible).

[danhper]

timestamps in the DLS you showed presents the same problem

I understand you point, and the point of this warning,
but often a DSL is used as something declarative,
where overriding something by mistake is very unlikely to happen.
For example, let's say we have a DSL to write HTML.

html do
  body do
    h1 "foobar"
    br()
  end
end

Having to make an explicit function call here kind of looses the beauty of the DSL in my opinion.

[josevalim]

@tuvistavie it depends on the DSL. Some DSLs will bypass this warning by simply annotating those variables as generated or by translating the AST. For example, foo |> bar |> baz won't warn because bar is never really called as is.

[danhper]

@josevalim Thank you for the explanation.
So I suppose the best thing to do is to handle this at the DSL level
by changing these kind of calls into macros and making sure we don't trigger the warning, right?

[josevalim]

Yes, that's a possibility, definitely. We will continue collecting feedback on this in any case. :)

[voltidev]

I use Elixir 1.3.2 and I don't see the warning when I try this code:

defmodule WarningTest do
  defp do_stuff, do: 'stuff'

  def my_func do
    do_stuff
    a = do_stuff
  end
end

[lexmag]

@ivanvotti this warning will be part of Elixir v1.4.0.

[hellerve]

Late to the party, but I cannot seem to find this in the v1.4.0 changelog. Is there any reason this was omitted?

[josevalim]

[Kernel] Warn if variable is used as a function call

https://github.com/elixir-lang/elixir/blob/v1.4/CHANGELOG.md

[hellerve]

Okay, searched for bare words and arity. Sorry for the noise, then.

[josevalim]

No problem!