This is sad but okay, it's better to ensure consistency, otherwise some bug reports could arise of people enumerating a range and reusing it with different output :/
Should i PR to add a comment to the "in" to state that it will only succeed with ranges if the value is an integer ? On Wednesday, February 8, 2017 at 2:09:45 PM UTC-2, José Valim wrote: > > Ranges originally worked as you proposed but we changed it to the restrict > form we have today exactly because of the confusion that arose from the > fact ranges with floats cannot be enumerated as in Enum.to_list/2. This > meant that: > > Enum.member?(1.5, 1..2) #=> true > > but > > Enum.to_list(1..2) #=> [1, 2] > > and it also meant that: > > Enum.member?(1.5, 1.0..2.0) #=> true > Enum.to_list(1.0..2.0) #=> raises > > Those inconsistencies are not worth the small benefits. > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > On Wed, Feb 8, 2017 at 4:48 PM, <[email protected] <javascript:>> > wrote: > >> Right now when you write something like >> >> x in -1..1 >> >> elixir compiles it to >> >> is_integer(x) and x >= -1 and x <= 1 >> >> >> If we were to write >> >> x in Enum.to_list(-1..1) >> >> It would have the exact same effect (as x would have to be an int that is >> bigger than or equal to -1 and lesser than or equal to 1 to pass) which >> makes sense when we look at Ranges as being just a lazily-evaluated >> enumerable (like a Stream). >> >> But i think that we should consider a range (atleast in the context of an >> "in" operation) equal to a space. Right now if we were to check if a float >> is inside a range, it would always fail (which, again, makes sense if we >> see the Range as a lazy enum). >> >> What i propose is that elixir accepts floats when executing "in" for a >> range. I believe it semantically makes sense (as in "0.5 is a number in the >> -1..1 range ?" instead of "0.5 is inside the list of integer produced by >> the -1..1 range/sequence") >> >> So, tl;dr, changing Kernel's macro in_range_literal/3 to >> >> (is_integer(x) or is_float(x)) and increasing_compare(a, b, c) >> >> >> That way we can easily check things like >> >> def valid_probability?(val), do: val in 0..1 >> >> def contains_enough_products(amount), do: is_integer(amount) and amount >> in 1..10 >> >> >> Note that in the above example i shown that you explicitly checks if the >> value is integer when you want it to be, which i believe is not a bad >> side-effect to this proposal (and i think that it is not obvious that this >> is the default behaviour, specially because the documentation doesn't >> states that ranges won't succeed with floats) >> >> -- >> 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] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/4a5be52c-59eb-43e5-bc40-abcf5034a59f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/4a5be52c-59eb-43e5-bc40-abcf5034a59f%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/f3c0619d-45e5-4746-a6cb-f75841824e1f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
