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
Short-hand version of attributes on structure items and class fields #6586
Comments
Comment author: @lpw25
You can put extensions as class fields:
|
Comment author: @Drup Oh, indeed. I wonder why I miss it. I even saw it in the parsetree .... |
Comment author: @alainfrisch I wonder if accepting the short notation for extension on 'let' structure items was such a great idea. It's nice that the syntactic marker (% vs %, @ vs @@) makes it clear whether the extension/attribute is on an expression or a structure item. For "let[@foo] x = 3", there is a technical problem: item-attributes are attached to individual value_binding, not to the entire let structure item. So in case of "let[@foo] x = 1 and y = 2", there is no natural place to attach the attribute; we could decide it's always on the first value binding, but since the attribute in syntactically attached to the 'let', this would be quite arbitrary. |
Comment author: @damiendoligez Do we have an idea to solve frisch's "technical problem"? |
Comment author: @alainfrisch The short-hand notation is currently only recognized just after the initial keyword ("let"), i.e. in the same location where an extension %foo could appear. Clearly, it doesn't make sense to allow "let f = 3 and%foo y = 4", so what you suggest would introduce the only context where the short version is allowed for attributes but not extensions. Perhaps more importantly, consider: let[@foo] x = 3 in x There, @foo is attached to the whole expression (as for any attribute introduced with the short notation after a keyword), not to the "x = 3" binding. |
Comment author: @Drup I agree that the current behavior is not consistent with the way other attributes behaves. Attributes don't behave the same on local let and top-level let. However, if we don't change the way they behaves, the syntax I gave makes perfect sense. We could change the behavior of attributes on top-level let so that they behaves the same way than on local let, I personally don't have any opinion on that. |
Comment author: @alainfrisch
Do you refer to: "let[@foo] x = 3 and[@bar] y = 4" is equivalent to "let x = 3 [@@foo] and y = 4 [@@bar]" It seems really confusing to have the same form "let[@foo] x" interpreted very differently for top-level bindings and for let-in bindings. I'd rather stick to the current behavior: (i) item-level attributes always use [@@] and (ii) attributes introduced with the short-form "KEYWORD[@foo] REST_OF_EXPRESSION" are interpreted as "(KEYWORD REST_OF_EXPRESSION)[@foo]". If you really insist on your proposal, can you try to give some use cases? |
Comment author: @Drup I had one use for methods (annotations on methods for js object literals) but I don't remember for top-level let at the moment. I think the behavior of attributes on toplevel let is confusing from the beginning and it's even more clear with the additional syntax. |
Comment author: @damiendoligez |
Original bug ID: 6586
Reporter: @Drup
Status: closed (set by @damiendoligez on 2016-04-12T13:05:04Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.02.0+beta1 / +rc1
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: ~DO NOT USE (was: OCaml general)
Related to: #6623 #6677
Monitored by: @gasche @hcarty
Bug description
For expressions, the following short-hands are available:
let%foo x = 3 in e
let[@foo bar] x = 3 in e
For structure items, you can do the first, but not the second.
For class fields, "method foo = bar [@@attr payload]" is accepted, but not "method[@attr payload] foo = bar" (You can't put extensions as class fields, so the other issue is not a problem there).
The text was updated successfully, but these errors were encountered: