Re: [elixir-core:6678] Re: I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

The warning was first meant to be introduced on Elixir v1.3 but we have delayed it because we had other warnings introduced in that version, such as the xref ones, and we wanted to call attention to those. On this version we have focused mainly on the variable warnings because we understand they

[elixir-core:6678] Re: I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

I'm dead against this warning. Sure, I've tripped over this issue a few times, but the benefit of this change is not worth the cost IMHO. I'll have to update all my commercial projects, my open source projects, and likely fork/submit PRs on some of my 3rd party dependencies. Until all that is

Re: [elixir-core:6676] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

Btw Dave, it is really nice to see you are exploring a property testing library. When Andrea proposed for one to be introduced in Elixir, I said we should explore the ability of building generators as streams and that's exactly what you did with pollution. I loved "when factories meet streams". I

Re: [elixir-core:6675] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

> Basically, what compelling problem drove this change? It isn't an issue I ever had before, and the change seems to make my code worse. There were a couple scenarios that I either personally ran into or were frequently reported. One of those came from Plug test suite. In Plug it is common to

Re: [elixir-core:6673] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

Actually could this be solved externally to the language with a static code analysis tool? Amos King Binary Noggin > On Dec 3, 2016, at 08:34, Allen Madsen wrote: > > It looks like this was already discussed here: > https://github.com/elixir-lang/elixir/issues/3268

Re: [elixir-core:6672] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

I understand that the anonymous function is both a value and a function which is why we have to call it with parentheses. I don't understand why it needs the dot. Seems the only time that would become confusing is if you had a first class function and an Anonymous function with the same name.

Re: [elixir-core:6671] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

It looks like this was already discussed here: https://github.com/elixir-lang/elixir/issues/3268 https://github.com/elixir-lang/elixir/pull/3517 I prefer bare words for the same reason as Amos. It facilitates refactoring between methods and variables. If this stays, is it expected to be a

Re: [elixir-core:6670] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

In my experience the minimize scope of data binding keeps it pretty straightforward. Amos King Binary Noggin > On Dec 3, 2016, at 07:50, Michał Muskała wrote: > > The ambiguity, that bit me already several times is in the code that looks > like this: > >self = self()

Re: [elixir-core:6669] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

The ambiguity, that bit me already several times is in the code that looks like this: self = self() do_something(self) Now the self in the second line can be both - calling the function and accessing variable. Of course it's not confusing in this example because of it's brevity, but

Re: [elixir-core:6668] I think the new 1.4 warning about missing () on zero arity functions is a cure that's worse than the disease

I prefer being able to use the bare words. It makes refactoring simpler to move between a variable and a method which I do regularly. The warning seems strange since there isn't an ambiguity that is being decided. I'm on board with Dave here. Amos King Binary Noggin > On Dec 3, 2016, at

Re: [elixir-core:6667] [Proposal] Deprecate default String.Chars implementation for Float

Thanks for the example, I will investigate it. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R On Sat, Dec 3, 2016 at 1:19 AM, Bryan Enders wrote: > v1.4 is using :io_lib_format.fwrite_g/1, which provides the ‘*shortest*, > correctly