-
Notifications
You must be signed in to change notification settings - Fork 30
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
Change for SIP-62: betterFors #99
base: main
Are you sure you want to change the base?
Conversation
I suppose that the manager stays the same. ping @lihaoyi |
I think this looks reasonable, bit i dont know enough about dotty internals to know what rhe consequences of this would |
Ping @sjrd |
|
||
This kind of effect loop is pretty commonly used in Scala FP programs and often ends in `yield ()`. | ||
|
||
The problem with the desugaring of this for-comprehensions is that it leaks memory because the result of `loop` has to be mapped over with `_ => ()`, which often does nothing. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will it then be desugared to two foreach
s? as the _
will never be used anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In this case, it should end up with just one flatMap
. It will eliminate the last map
call. This is also what bm4 would do in this situation.
A proposal of a new approach for implementing change
3
from SIP-62: betterFors.TLDR:
Don't drop the trailing
map
when desugaring. Instead, mark the lastApply
node with aTrailingForMap
attachment and move the optimization to a later phase (after typing). This way, we can make sure that the resulting type of thefor
doesn't change.