I just want to throw in my two cents. I don't think a warning should be generated if there is no ambiguity about a name. I see warnings primarily as a means of saying "hey, you've done this thing, and it may not behave the way you expect it to, or may cause errors at runtime, you should change it to this other thing instead", not "hey, you've done this thing, and there's no problem with it now, but there could be, maybe". If warnings are not of the former type, then they should be warnings which can be disabled with a compiler flag, because it becomes a question of style vs actually warning about an unsafe condition.
Personally, if I have to append all zero-arity function calls with parens, I can deal with it, but I find it pretty annoying that it's something I have to go update all my code to address, just because it *might* cause a problem for me, or someone else, if a certain set of conditions are met in the future. If, on the other hand, a warning was generated *because I actually met those conditions*, it would be helpful, and would likely tell me to be more conscious and careful in order to prevent making the same mistake again in the future. I find it a little difficult to understand why always warning is preferable to warning conditionally for this one. Paul On Sun, Dec 4, 2016 at 7:49 PM, Dave Thomas <[email protected]> wrote: > > The more I explain this, the clearer it becomes to me variables and >> functions have no business in stepping on each other's namespaces. >> > > Except that classically a variable is simply a zero arity function with a > shorthand creation syntax. > > OK, one more try. If I say `Mod.a`, then 1.4 (correctly) treats it as a > call—I don't need the ()s. A bare function call means the current module. > So could we also support `.a` as a function call in the default module? (I > know the answer to this. But I wanted to trigger some lateral thinking on > your part. Some part of me is sure that this () thing is a move in the > wrong direction, and I'd really like to find the magic button to help you > see it too) > > If you keep these warnings going forward, I don't think you should change > iex—it should be consistent with the rest of the language. > > > -- > 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/61d33cd3-23e8-4606-a27a- > fb0bc9d7f1ad%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/61d33cd3-23e8-4606-a27a-fb0bc9d7f1ad%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/CAK%3D%2B-TsiTABAhYAn1G%2BfcfGXHDHQa5Hth7unOAs6UN5%2BQQ7ZVA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
