-
Notifications
You must be signed in to change notification settings - Fork 3k
Make assignment (match) in comprehension work as strict generator #9153
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
CT Test Results 6 files 571 suites 1h 59m 16s ⏱️ Results for commit 1c1c525. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
|
Turned into a feature. Becomes an error if it occurs when the feature is not enabled. Also fixed multiple problems with the features implementation. |
5f98841 to
0ddf501
Compare
24cd657 to
30293d7
Compare
|
Rebased on #10376 to make the Features fix a separate thing. |
30293d7 to
445095a
Compare
The test still exercises the same type conflict bug.
445095a to
1c1c525
Compare
|
Rebased again and updated feature introduced version to 29. |
Implements EEP 77 (erlang/eep#74)
It would be useful to be able to easily bind variables in the qualifiers of a comprehension, for example:
You can do this today by writing a singleton generator:
but this has some drawbacks: the intent is not clear to the reader; you have to remember to write a single element list around the right hand side argument (which itself could be a list); you probably want it to be a strict generator so typos don't just silently yield no elements; and someone might edit the code later and accidentally add extra elements to the right hand side, causing unintended Cartesian combinations.
It is in fact already allowed syntactically to have a
=match expression in the qualifiers, but this is just interpreted as any other expression - thus expected to produce a boolean value, and if false, the current element will be skipped. Hence, any qualifier to the right of aV = Exprmatch will only execute if V is true. We can therefore expect that no such uses exist in practice. (The OTP code base has been checked and does not contain any.) To be completely safe, matches in a comprehension qualifier position can first be made an error, and then allowed with these binding semantics in the following major release.This is related but orthogonal to #9134. It would make those few cases where variables have been exported from subexpressions of qualifiers much nicer to rewrite than requiring them to be singleton generators.