You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today ranges without an explicit step have their step inferred based on start..stop, but instead we should default to always be 1. Given this is a breaking change, it has to be assigned to Elixir v2.0 (which is still not planned nor scheduled).
The goal is to deprecate most of those cases early on, to avoid surprises down the road. We should also consider adding a elixir --future flag that allows developers to run and compile their codebase with these changes early on.
The text was updated successfully, but these errors were encountered:
Would an alternative be to consider a scheme asimilar to Rust editions? Given this would be a pure compile-time change it would be possible to control this behaviour in the compiler, keeping full runtime compatibility, and importantly allow code with old & new behaviour to live together, making the migration much easier.
The change also happens at runtime if you are calling Range.new. That's why I thought a flag is a good approach: you either run everything with the flag, or everything without the flag, and Mix should check the flag to give you different builds. The only real use is to see if your app will run fine on Elixir v2.0 (which is still a long time ahead).
Today ranges without an explicit step have their step inferred based on start..stop, but instead we should default to always be 1. Given this is a breaking change, it has to be assigned to Elixir v2.0 (which is still not planned nor scheduled).
The goal is to deprecate most of those cases early on, to avoid surprises down the road. We should also consider adding a
elixir --future
flag that allows developers to run and compile their codebase with these changes early on.The text was updated successfully, but these errors were encountered: