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

I personally think this is clearer, and I don't feel this is clearer. With this I think it is easier to tell when computation is happening- previously it could be hidden behind what looks like variables. Cheers, Louis On Sat, 3 Dec 2016, 04:42 Dave Thomas, wrote: > I’ve been

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

I’ve been loving 1.4 for a few weeks now, but I am bugged by the new warning: warning: variable "int" does not exist and is being expanded to "int()", please use parentheses to remove the ambiguity or change the variable name Partly it is because it makes my code a lot uglier. For

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

I've been living with 1.4 for a few weeks now. I am bugged by the new warning: ~~~ warning: variable "int" does not exist and is being expanded to "int()", please use parentheses to remove the ambiguity or change the variable name

Re: [elixir-core:6663] Adding __APP__ or something similar

I think I like the App.defmodule more than the other solutions. It is more focused on the area of concern and doesn't need to be a new part of Elixir. Amos King Owner Binary Noggin http://binarynoggin.com #business http://thisagilelife.com #podcast

Re: [elixir-core:6662] Adding __APP__ or something similar

The defmodule macro is also something `use Application` could inject for us, i.e.: defmodule Phoenix do use Application, alias: Phoenix end > On Dec 2, 2016, at 5:05 PM, Chris McCord wrote: > > I’m not yet sure how I feel about adding a feature to the language to

Re: [elixir-core:6661] Adding __APP__ or something similar

I’m not yet sure how I feel about adding a feature to the language to solve this issue since I don’t think it’s hard to solve with find/replace and I’ve come to prefer the explicit, if not a little boilerplate'y namespacing. For the moment, I probably lean more towards -1. That said, I don’t

Re: [elixir-core:6660] Adding __APP__ or something similar

I realize they aren't proposals, but I do like #1, perhaps with an eye toward having @MODULE in conjunction with __MODULE__ for a time before eventually deprecating the latter. Alternatively we could have @@compiler_attributes and @module_attributes because it would amuse me to have module

Re: [elixir-core:6659] Adding __APP__ or something similar

As Michał said, I don't think we want exactly __APP__. After all, the application name is an atom, like :my_app, and we likely want the inflected application module, which would be MyApp. Furthermore, as Michał also said, the inflection does not automatically work for all applications, so I

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

I believe that's how it works today or at least how will it work on Elixir v1.4 (i.e. it is what I see in my terminal around). *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R On Fri, Dec 2, 2016 at 9:48 PM, Bryan Enders wrote: > The

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

The current behavior (shortest representation, whether E notation or decimal) is perfect for IO.inspect and Kernel.inspect. For Kernel.to_string I would use decimal representation unless the float is at such a size where compaction occurs, then I would use E notation. On Friday, December 2,

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

The problem is that we cannot correctly encode a float after certain decimal digits. For example, a float like 123_123_123_123_123_123_123 cannot correctly be shown as 123123123123123123 because there is no precision at the last digits, in such cases a sort of compactation, such as scientific

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

That makes sense. In that case, I retract my proposal. I do think we should discuss changing the formatting of floats, especially since *(scientific) E notation* is discouraged in general communication. On Friday, December 2, 2016 at 11:02:59 AM UTC-5, José Valim wrote: > > We can discuss

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

We can discuss improving the formatting for floats but it is important to leave the Principle of Least Astonishment at the door because different people are going to have different expectations of what is the least surprising and we would be unable to reach an agreement. We implement

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

That’s a good point, José. It does make unexpected assumptions with regards to formatting (scientific notation when it’s shortest, decimal otherwise), but I was incorrect in asserting that it makes assumptions with regards to precision. The String.Chars implementation for Date makes formatting

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

> String.Chars.to_string/1 is only implemented by default for types that can be represented with unambiguous precision… with the exception of Float. A float number can be represented as a string with no ambiguity. There are many papers that explain how to do so quickly and accurately, the earlier

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

> > the utility of not having to format the float for interpolation/logging > for such a core type is worth keeping the behavior Couldn’t the same be said of all the basic types, including tuples, maps, ranges, and processes (arguable *the* essential type of Erlang/Elixir)? Providing a

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

*Note: *Unlike String.Chars.to_string/1, Kernel.inspect/1 is allowed to take liberties. Consequently, it can provide string representations of all types. On Friday, December 2, 2016 at 9:39:44 AM UTC-5, Bryan Enders wrote: > > String.Chars.to_string/1 is only implemented by default for types

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

I am -1 on this one. I agree that explicit formatting and rounding will be required for times that you care about how the float is printed, but the utility of not having to format the float for interpolation/logging for such a core type is worth keeping the behavior in my opinion. > On Dec 2,

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

String.Chars.to_string/1 is only implemented by default for types that can be represented with unambiguous precision… with the exception of Float. The ambiguity with regards to representing tuples and maps (and by extension structs) would seem to be the primary reason for omitting a default