Skip to content
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

Draft: comprehension assignment #74

Merged
merged 1 commit into from
Jan 23, 2025

Conversation

richcarl
Copy link
Contributor

@richcarl richcarl commented Jan 10, 2025

This EEP adds assignments to comprehension qualifier lists.
Reference implementation PR: erlang/otp#9153

eeps/eep-0076.md Outdated
executed if `Var` has the value `true`. We can therefore expect that
no such uses exist in practice, because `Var` would be fully
redundant. (The OTP code base has been checked and does not contain
any.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say this is still a backwards incompatible change, because if someone relies on it, the behaviour will change in very subtle ways:

2> [{X, Y} || X <- [1, 2.0, 3], Y = is_integer(X)].
[{1,true},{3,true}]

Also, for completeness, one could introduce maybe expressions' ?=operator in comprehensions, which would work similar to an assignment + filter (as it will discard the element if it does not match the pattern).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is an incompatible change, yes. To protect against that, one could start with making Pat = ... an error in OTP 28, and then add the new interpretation in OTP 29. I really did not want to add yet another special token. (?= could be useful though). One possibility is to use the so far reserved token 'let' as a prefix: let Pat = ..., ....

Copy link
Contributor

@michalmuskala michalmuskala Jan 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an option of making it an error in 28, and introducing an opt-in feature that uses the new semantics (rather than erroring), and in 29 making this feature the default.
This way, it won't silently change semantics, but won't delay the new syntax for another release for people that are ready for it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a winner to me.

@richcarl richcarl changed the title Add draft for eep 76: comprehension assignment Draft: comprehension assignment Jan 10, 2025
@richcarl richcarl force-pushed the comprehension-assign branch from 8c54377 to 628c65e Compare January 11, 2025 15:50
@richcarl richcarl force-pushed the comprehension-assign branch from 628c65e to 0a3486d Compare January 11, 2025 16:00
@kikofernandez kikofernandez self-assigned this Jan 15, 2025
@kikofernandez
Copy link
Contributor

We will review this in the near future.

Thanks for your contribution

@kikofernandez
Copy link
Contributor

@richcarl We will wait a bit to see how the community (Erlang Forums and interested people reading this EEP) sees this change. Thanks

@kikofernandez kikofernandez merged commit 0c9ad45 into erlang:master Jan 23, 2025
1 check passed
@richcarl richcarl deleted the comprehension-assign branch January 23, 2025 13:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants