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

please allow value definitions before the first generator in a for comprehension #907

Open
scabug opened this issue May 14, 2008 · 11 comments

Comments

@scabug
Copy link

commented May 14, 2008

I would like to be able to write this:

for{x = foo(bar); y <- x} ...

the language spec (6.19) says "An enumerator sequence always starts with
a generator", but why? From time to time I would find it convenient to put
a value definition first. I realize that in the above code I only use x once,
but I've hit this in real code where I want to use x more than once.

(Perhaps "if" should be allowed too?)

@scabug

This comment has been minimized.

Copy link
Author

commented May 14, 2008

@scabug

This comment has been minimized.

Copy link
Author

commented Feb 19, 2009

@paulp said:
While I agree with the sentiment on an aesthetic level, the overhead of such a change (in implementation and testing as well as updating the language spec, documentation, and etc.) has been deemed too high to justify it, as the known use cases are marginal. So I'm closing this as wontfix, but please update the ticket if you come across a compelling motivation.

@scabug scabug closed this May 18, 2011

@scabug

This comment has been minimized.

Copy link
Author

commented Dec 11, 2016

@som-snytt said:
It's pretty compelling that Seth is now in a position to do whatever he likes with a three-digit issue.

@scabug

This comment has been minimized.

Copy link
Author

commented Apr 2, 2017

Samuel Halliday (fommil) said:
Is there any reason this couldn't be implemented as a parser rewrite to move the value definition out of the for?

e.g. rewrite Seth's original example as

val x = foo(bar)
for {y <- x}
@fommil

This comment has been minimized.

Copy link

commented Apr 25, 2017

I'd really like to see this ticket reopened.

@jvican

This comment has been minimized.

Copy link
Member

commented Apr 25, 2017

I'm not sure this workaround:

val x = foo(bar)
for {y <- x}

is worth it. I think we have already enough desugarings in parser. Putting more would force all the Scala tooling to catch up and I don't think it's a neat solution overall, but rather a hack.

@fommil

This comment has been minimized.

Copy link

commented Apr 25, 2017

for FP code this is definitely worth it. This comes up all the time when for is your main language structure for sequential code.

@fommil

This comment has been minimized.

Copy link

commented Apr 25, 2017

@SethTisue SethTisue added this to the Backlog milestone May 9, 2017

@SethTisue

This comment has been minimized.

Copy link
Member

commented May 9, 2017

it appears this was closed because the core team at the time didn't intend to tackle it, not because it would necessarily be rejected if it came in as a community contribution (including the necessary spec work and so forth)

@SethTisue SethTisue reopened this May 9, 2017

@SethTisue

This comment has been minimized.

Copy link
Member

commented May 9, 2017

@SethTisue

This comment has been minimized.

Copy link
Member

commented Dec 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.