I used to be on Dave’s side of the argument, but after seeing people get bit by the ambiguity over and over, including myself, I’m definitely for this change. Even with a heightened awareness of the issue, I still find I will occasionally waste cycles on frustrating debugging to find it was a null arity function call where I thought there was a variable reference. `foo()` vs `foo` is slightly less beautiful in my eyes, but its alignment with explicit over implicit wins out.
> On Dec 5, 2016, at 9:25 AM, Ólafur Arason <[email protected]> wrote: > > I don't have horse in the race, I'm fine with either 2 or 3. But like with > def, defmodule, @attributes and other uses of non parenthesis function > calls, there are nice uses of non parenthesis in zero arity functions. But > like you have stated there are some really bad problem that can arise and > it makes the code unclear sometimes. I only proposed option 3 because it > would cover most of the problems with the dual use of names. But I also > do realize that it's harder to implement and might not be a perfect solution. > > It's like reusing variable name, it's not necessary, it causes some problems > but > it's sometimes better than: > green = green() > > Regards, > Olaf > > On Monday, 5 December 2016 07:16:33 UTC-5, José Valim wrote: > To further clarify the previous response, we have three options: > > 1. Do not warn if a variable is used as a function call (Elixir v1.3) > > 2. Warn if a variable is used as a function call (Elixir v1.4) > > 3. Warn if there is a variable and a function with the same name (proposed in > this thread) > > The response above was about option 3. I consider it to be the worst option > because it solves less than half of the problems the warning was meant to > solve while having introducing drawbacks that do not exist in options 1 and 2. > > So if you believe 3 is still the way to go, please *elaborate on the points > on why it is a good reason* and why you agree or disagree with the drawbacks > previously explained. > > José Valim > www.plataformatec.com.br <http://www.plataformatec.com.br/> > Skype: jv.ptec > Founder and Director of R&D > > On Mon, Dec 5, 2016 at 1:06 PM, José Valim <jose....@ <>plataformatec.com. > <http://plataformatec.com.br/>br <http://plataformatec.com.br/>> wrote: > > I think that if you have introduced a var anywhere in your module that has > > the same name as a zero arity function then this warning should be shown > > that solves all the problems that have been stated. > > I have explained in a previous reply why this is harmful and why it does not > solve all the problems stated. The warning will not only show up when you > introduce a variable, but also when you introduce a new function in the > module and that will trigger warnings in unrelated part of the code. > > While having the discussion is important, it is also important to move the > discussion forward. This is the third or fourth time that "emit a warning > only if there is a variable and a function" is proposed after it was already > explained why such is considered harmful. This means either 1. the previous > reply was not read, which is frustrating because it puts me in the position > of repeating the same points over and over again, or 2. the previous reply > was read but folks don't agree with its conclusions. If the latter, nobody is > explaining *what they don't agree with*, which does not allow the > conversation to move forward. > > I will copy the reply on why warning only if there is a function is a bad > idea one last time: > > > So going back to the cases the current warning is meant to solve that I > > sent in an earlier email, warning only if it shadows a function, does not > > solve the first case although it does also solve the second case. > > > However, it does not solve the contextual overhead, When changing or > > reading code, I still need to carefully look at the surrounding context to > > see if the variable is not being used in order to avoid the warning (or I > > can write the code and wait for the compiler to tell me). > > > But to make things worse, the suggestion of only warning if there is a > > function, means that by simply adding a function into a given module, you > > may now get warnings on other functions in that same module, simply because > > you defined a new function 100LOC below. It is even worse if you consider > > imports: if you are importing or using an external library and it adds a > > new function to its API, you may have warnings when updating your > > dependency. > > > Those are really undesired consequences. I believe we should either define > > that one of them has higher precedence (Elixir v1.3) or make sure they > > don't conflict (Elixir v1.4). > > I would love to continue the discussion but if it ultimately ends up with me > repeating previous points, it will eventually lose interest. > > > José Valim > www.plataformatec.com.br <http://www.plataformatec.com.br/> > Skype: jv.ptec > Founder and Director of R&D > > On Mon, Dec 5, 2016 at 11:57 AM, Ólafur Arason <olaf...@ <>gmail.com > <http://gmail.com/>> wrote: > I think that if you have introduced a var anywhere in your module that has > the same name as a zero arity function then this warning should be shown that > solves all the problems that have been stated. > > We compile our code with warnings as errors so it's very important for us to > have warnings that point out problems in our code. > > I feel like the sentiment about being able to use zero arity function without > parentheses is pretty split in this thread. If there was a consensus about > this warning I would be fine with it. > > Regards, > Olaf > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to elixir-lang-co...@ <>googlegroups.com <http://googlegroups.com/>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/874996b8-6759-4a77-be31-d7e050cd6123%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/874996b8-6759-4a77-be31-d7e050cd6123%40googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > > -- > You received this message because you are subscribed to the Google Groups > "elixir-lang-core" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/a9fd5f51-f302-49ff-b228-04ff2ff248bd%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/a9fd5f51-f302-49ff-b228-04ff2ff248bd%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/F70227D9-DD4A-4962-9330-8F3DD3283B3E%40chrismccord.com. For more options, visit https://groups.google.com/d/optout.
