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.

Sign up for GitHub

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

Jump to bottom

Should unary form have a static restriction? #4

Closed
zenparsing opened this issue Mar 8, 2015 · 5 comments
Closed

Should unary form have a static restriction? #4

zenparsing opened this issue Mar 8, 2015 · 5 comments
Labels
Open Question

Comments

@zenparsing
Copy link
Member

Should the unary form have a static (or even runtime) restriction such that the operand must be a reference type (basically, a property access)?
@ckknight
Copy link

ckknight commented May 9, 2015

I'd say yes, otherwise what would ::foo represent on its own?

@zenparsing
Copy link
Member Author

Without a restriction, it would bind foo to undefined. Such a binding ought to be written as undefined::foo though, so an error make sense.

This was referenced May 13, 2015
Closed
Merged
@zenparsing zenparsing mentioned this issue May 16, 2015
Closed
dead-claudia pushed a commit to dead-claudia/es-function-bind that referenced this issue May 16, 2015
NewExpression -> MemberExpression (for unary form)
da2b9fd 
tc39#4: No good use case for it.

There are only two possible use cases for `::func`:

1. You want to bind the function to `undefined` so it cannot be re-bound by the caller.
  - Use `undefined::func` or `func.bind(undefined)` as it's more explicit of the intent.
2. You just want to pass the function as an argument.
  - Binding is unnecessary here. Just use `func`.

Because `::func` is equivalent to `func.bind(undefined)`, and `func()` is equivalent to `undefined::func()`, there is no other use case for this.
@dead-claudia dead-claudia mentioned this issue May 16, 2015
Closed
@zenparsing
Copy link
Member Author

@RReverser I've written up the early error rule similar to the early error rule for "delete", so that the operand can be parenthesized. If that looks good, we'll eventually need to update the parser to allow things like:

::((foo.bar))

@RReverser
Copy link
Contributor

@zenparsing My implementation already allows things like that.

@RReverser
Copy link
Contributor

So yeah, let's go ahead and resolve this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Open Question
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ckknight @RReverser @zenparsing