I'm not sure what backwards compatibility means when it comes to typespecs
or if we have any rules for it in Elixir. All code still works the same way
when changes are made to typespecs so what is the potential
incompatibility? External tools (like dialyzer) may be affected but we
don't control tho
On Mon, Jul 4, 2016 at 10:40 PM, Dave Thomas wrote:
>
> FWIW, I think I'd still prefer to ban rebinding outer scope variables
> inside if, for, cond, etc. it would simplify the semantics and would
> encourage a more functional style.
>
The warning is a step in that direction, although not all the
Great catch. Docs are welcome, please. :)
*José Valim*
www.plataformatec.com.br
Skype: jv.ptec
Founder and Director of R&D
On Mon, Jul 4, 2016 at 11:25 PM, Dave Thomas wrote:
> I ask because it has no documentation.
>
> If needed, I can write some and submit a PR.
>
> Dave
>
> --
> You receiv
I ask because it has no documentation.
If needed, I can write some and submit a PR.
Dave
--
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 elixir-lang-core+u
>
>
> Variables set inside "for" do not pass to the next iteration. For the
> first case, the compiler believes there is a chance (given the compiler
> does not execute the condition) that "a" will be accessed after reassigned.
> For the second case, the compiler knows a 100% sure nobody will e
>
> Correct, and so I am accessing a variable that was rebound inside an if,
> after the rebinding, and I don't get a warning.
>
Variables set inside "for" do not pass to the next iteration. For the first
case, the compiler believes there is a chance (given the compiler does not
execute the condit
>
>
> In other words, the code executed is the same, but the code compiled is
> not the same, and the compiler doesn't know (much) about the execution
> branches.
>
Correct, and so I am accessing a variable that was rebound inside an if,
after the rebinding, and I don't get a warning.
The co
Right, the compiler won't analyze the conditions and know that only one of
those are executed. It could if we want to detect those branches are
mutually exclusive but I guess we wouldn't gain much as those are likely
case and cond's in practice?
In other words, the code executed is the same, but t
The order of execution is only the same because i cannot equal both 1 and
2. If both conditions could be satisfied, then the order of execution would
indeed be different. To the compiler, I would assume it pessimistically
assumes the two conditions are not mutually exclusive and therefore
assigning
The code executed is identical in the two examples. The difference is the
order of the source, not the order of execution.
On Mon, Jul 4, 2016 at 2:47 PM, José Valim
wrote:
> In your second example you never use the variable after you assign it
> inside the if. They are slightly different code
In your second example you never use the variable after you assign it
inside the if. They are slightly different code samples, I am missing the
connection.
On Monday, July 4, 2016, Dave Thomas wrote:
>
>> As my original code showed, the compiler _cannot_ know whether it is used
>>> after the ass
>
>
> As my original code showed, the compiler _cannot_ know whether it is used
>> after the assignment.
>>
>
> Unless I misunderstand the assertion, the compiler always knows all
> variables that are used.
>
Have a look at the original post. The same code got executed in both cases,
but in on
> x = 42
>> if foo do
>> x = x + 1
>> IO.puts x
>> end
>> # x is never used again
>>
>>
> Correct, and I think it should do, for exactly the same reasons.
>
Why? It is never ambiguous what the value of "x" is. If you never use it,
there is no "leaking" of variables, which is the problem the wa
On Sunday, July 3, 2016 at 8:54:04 PM UTC-5, Eric Meadows-Jönsson wrote:
>
> What’s unsafe is that you are using a variable that may or may not have
> been modified inside a previous inner scope.
>
> If we did the change you are proposing the following code would also warn:
>
> x = 42
> if foo d
I just noticed that the Enum.index/0 type is set to `non_neg_integer`,
the thing is that indexes are `integer`.
as of now, it is only used one in the whole elixir code base,
in Enum.find_index/2
The rest of the times, when we need to represent an index, we need to
use `integer`,
I know this chang
15 matches
Mail list logo
