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
(It's not possible to have an arbitrary variable in default values, - but it's possible to have a variable in some places inside lambdas of comprehensions, and such a variable may behave differently depending on the surrounding context).
Such default field values are inlined as they are during conversion of records in erl_expand_records. Conversion of records happens after initial linting (erl_lint) and erl_lint doesn't account for possible variables in default values for record fields, this results into an inconsistent behaviour in edge cases.
Compiling this code would result into variable 'Y' unsafe in 'case'
I have no opinion what would be the correct behaviour (a simplest one would be to ban all variables in default values for record fields), but the current behaviour is inconsistent.
The text was updated successfully, but these errors were encountered:
The documentation states the behavior that we want. the expressions by themselves are totally valid, since the newly introduced variables are just pattern matches. But then it becomes overshadowed with the test function parameter, that probably wasn't intended.
What you suggest is what we should do, ban all variables in default values for record, if you need variables in the function of a record, it's possible to make a record initializing function that sets default values, and then document in your API that it is how you are supposed to initialize your record.
This should avoid the overshadowing problem, and make it more consistent with the documentation.
Though it's possible to define records with variables in a default value for a field.
(It's not possible to have an arbitrary variable in default values, - but it's possible to have a variable in some places inside lambdas of comprehensions, and such a variable may behave differently depending on the surrounding context).
erl_expand_records
. Conversion of records happens after initial linting (erl_lint) and erl_lint doesn't account for possible variables in default values for record fields, this results into an inconsistent behaviour in edge cases.All warnings are wrong. Using erlc to just unfold the records and then compiling doesn't produce the same warnings.
The result of
erlc -E rec.erl
You can see now that
Y
vars intest1/1
andtest2/1
are actually used and affectY
vars from the default values.This code compiles, while if we first perform record unfolding and then try to compile, it doesn't compile.
After
erlc -E rec1.erl
Compiling this code would result into
variable 'Y' unsafe in 'case'
I have no opinion what would be the correct behaviour (a simplest one would be to ban all variables in default values for record fields), but the current behaviour is inconsistent.
The text was updated successfully, but these errors were encountered: