Throwing my 2c in: I'm for emitting the warning all the way. I vastly prefer reducing the cognitive load to "pretty" code, and personally I consider the call with parens way prettier than the call without (as it's clear that it's a function call, and there is no ambiguity). May be not strictly related, but this is the same reason why I always use parens on 0-arity functions called on a module that is stored in a variable, such as my_module.my_fun(), in order to avoid the cognitive load of having to find out if my_module is a module or a map.
Andrea Leopardi [email protected] On Mon, Dec 5, 2016 at 4:12 PM, Chris McCord <[email protected]> wrote: > 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 >> Skype: jv.ptec >> Founder and Director of R&D >> >> On Mon, Dec 5, 2016 at 1:06 PM, José Valim <[email protected]. >> <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 >>> Skype: jv.ptec >>> Founder and Director of R&D >>> >>> On Mon, Dec 5, 2016 at 11:57 AM, Ólafur Arason <[email protected]> wro >>> te: >>> >>>> 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 [email protected]. >>>> To view this discussion on the web visit https://groups.google. >>>> com/d/msgid/elixir-lang-core/874996b8-6759-4a77-be31-d7e050c >>>> d6123%40googlegroups.com. >>>> For more options, visit 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/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. > > > -- > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/F70227D9-DD4A-4962-9330-8F3DD3283B3E%40chrismccord.com?utm_medium=email&utm_source=footer> > . > > For more options, visit 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/CAM9Rf%2BKa09Q_jPS5isUWynZ6PfAiBWQ-ER7byTRD9A6X%3DvnFFw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
