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

for _ = e1 to e2 syntax is not allowed #6246

Closed
vicuna opened this issue Nov 26, 2013 · 5 comments
Closed

for _ = e1 to e2 syntax is not allowed #6246

vicuna opened this issue Nov 26, 2013 · 5 comments
Assignees

Comments

@vicuna
Copy link

vicuna commented Nov 26, 2013

Original bug ID: 6246
Reporter: @ygrek
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:25:24Z)
Resolution: fixed
Priority: normal
Severity: feature
Version: 4.00.1
Fixed in version: 4.02.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @gasche @diml @hcarty

Bug description

With the advent of the new warning 35 (unused for-loop index) it becomes natural to want this..

@vicuna
Copy link
Author

vicuna commented Nov 26, 2013

Comment author: @gasche

Makes perfect sense.

@vicuna
Copy link
Author

vicuna commented Nov 26, 2013

Comment author: @alainfrisch

You probably know it, but the warning can be silenced by using an identifier starting with "". And "__" (double underscore) is such a valid identifier. But yes, indeed, it makes sense to allow "" as for-loop index.

Users might expect that a context which allows both an identifier and _ would also support any pattern. Should we accept syntactically (and represent in the Parsetree) any pattern and reject those outside "_" and identifiers in the type-checker, or restrict the parser and Parsetree to only identifier and _ (represented as an "string loc option" in the Parsetree)?

@vicuna
Copy link
Author

vicuna commented Nov 26, 2013

Comment author: @gasche

I think rejecting in the type-checker would be best.

@vicuna
Copy link
Author

vicuna commented Nov 30, 2013

Comment author: @damiendoligez

I think accepting any pattern is just adding useless complexity to the compiler.

Also, why "string loc option" and not "string option loc" ?

@vicuna
Copy link
Author

vicuna commented Dec 2, 2013

Comment author: @alainfrisch

Commit 14330 on trunk. The parse accepts any pattern, and the type-checker fails on non-supported cases. I think this makes the Parsetree more self-documented (representing "_" as None would deserve some explanation) without really adding any kind of complexity. And one can imagine uses of other kinds of patterns by "extension expanders" (-ppx rewriters), such as list-comprehension stuff.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants