The wiki proposal doesn't mention what to do WRT the name property of functions created using bind.
I started down the path to specifying this but had second thoughts as I worked on it.
The main issue is that bind is a dynamic run-time operation and the value of a name property can not be statically determined as it is in most other cases.
Determining the a name is non-trivial computationally (accessing a property of the target, maybe doing a string concatenation, etc. I seems like a bad idea to require that overhead on every bind when in practice the name property will seldom be used for anything other than debugging.
Maybe an implementation might want to create one if a debugging mode is active but to always do it seems like a waste of runtime cycles.
The implementation of this is easy enough, without excess computation. Since the bound function already has a reference to the target function, it's easy enough to only resolve the name upon access of the property. Since the "name" property is non-configurable, the only case in which the access is observable is when the target function is a Proxy, which should be extremely rare.
Mozilla's implementation of function objects already has the various properties of functions hitting resolve hooks on access, so there's already evidence that lazy generation of function properties is feasible.
In terms of semantics, I think it could go either way. There's an argument to be made that a bound function is not semantically the same thing as the function it binds, because at the least the |this| binding will not match the target function, and often its parameters will also not match.
(In reply to comment #1)
> The implementation of this is easy enough, without excess computation. Since
> the bound function already has a reference to the target function, it's easy
> enough to only resolve the name upon access of the property. Since the "name"
> property is non-configurable, the only case in which the access is observable
> is when the target function is a Proxy, which should be extremely rare.
I pretty sure that we decided that "name" should be non-writable/configurable, just like the "length" and other similar properties changing to. That changes the observability.
The spec. can leave it open-ended whether name changes are obserable in the presence of things like Proxies. It has to take a stand one way or the other and follow through on the implications of that choice.
>
> Mozilla's implementation of function objects already has the various properties
> of functions hitting resolve hooks on access, so there's already evidence that
> lazy generation of function properties is feasible.
>
> In terms of semantics, I think it could go either way. There's an argument to
> be made that a bound function is not semantically the same thing as the
> function it binds, because at the least the |this| binding will not match the
> target function, and often its parameters will also not match.
If we have a name, I suggest we make it something like "bind <target name>" to distinguish bound functions from the original function. But I think it would be better and simpler if we just don't have a (auto generated) name property on bound functions.
decisions from April 2014 TC39 meeting
Just for reference: https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/apr-8.md#conclusionresolution-8
fixed in rev26 editor's draft
in rev26 draft