title: Why does `obj.foo = function() { };` not assign the name `foo` to the function?
body: <p>As of ES2015 (ES6), functions have proper names (including an official <code>name</code> property), and names are assigned when the function is created in a variety of ways in addition to the obvious function declaration and named function expression, such as assigning to variables (function's name is set to the variable's name), assigning to object properties (function's name is set to the property's name), even default values for function parameters (function's name is set to the parameter's name). But assigning to a property on an existing object (e.g., not in an object initializer) doesn't assign that property's name to the function. Why not? Surely there must be a <em>specific</em> reason it was not desirable/possible. What was it?</p>
  
  <p>To be clear: I'm not asking how to work around it. I'm asking what prevents this seemingly-obvious case from being handled when so many others (including default parameter values!) are. There must be a good reason.</p>
  
  <p><strong>Please don't speculate or theorize.</strong> TC39 had a reason for not including it. I'm interested in what that reason was. I've been through the <a href="https://github.com/rwaldron/tc39-notes">TC39 meeting notes</a> but haven't found it yet. The closest I've found so far is Allen Wirfs-Brock <a href="https://esdiscuss.org/topic/name-anonymous-functions-on-property-assignments">replying to Bergi</a> to say there was no consensus for doing it for that form because of "various objections," but sadly he didn't say what those objections were.</p>
  
  <p>Details:</p>
  
  <p>All of the following assign the name <code>foo</code> to the function on a <a href="https://kangax.github.io/compat-table/es6/#test-function_name_property">compliant browser</a>:</p>
  
  <p><div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
  <div class="snippet-code">
  <pre class="snippet-code-js lang-js prettyprint-override"><code>// Requires a compliant browser
  
  // Assigning to a variable or constant...
  // ...whether in the initializer...
  {
      let foo = function() { };
      console.log("1:", foo.name); // "foo"
  }
  {
      const foo = function() { };
      console.log("2:", foo.name); // "foo"
  }
  // ...or later...
  {
      let foo;
      foo = function() { };
      console.log("3:", foo.name); // "foo"
  }
  // As an initializer for an object property
  {
      const obj = {
          foo: function() { }
      };
      console.log("4:", obj.foo.name); // "foo"
  }
  // Or as a method
  {
      const obj = {
          foo() { }
      };
      console.log("5:", obj.foo.name); // "foo"
  }
  // Even if it's a computed property name
  {
      let name = "f";
      const obj = {
          [name + "o" + "o"]() { }
      };
      console.log("6:", obj.foo.name); // "foo"
  }
  // As a default value for a parameter
  (function(foo = function() { }) {
      console.log("7:", foo.name); // "foo"
  })();
  // ...and a bunch of others</code></pre>
  </div>
  </div>
  </p>
  
  <p>But assigning to a property on an existing object, outside an object initializer, does not:</p>
  
  <p><div class="snippet" data-lang="js" data-hide="false" data-console="true" data-babel="false">
  <div class="snippet-code">
  <pre class="snippet-code-js lang-js prettyprint-override"><code>const obj = {};
  obj.foo = function() { };
  console.log("Nope:", obj.foo.name);</code></pre>
  </div>
  </div>
  </p>
  
  <p>As far as I can tell, this is covered by <a href="http://www.ecma-international.org/ecma-262/7.0/index.html#sec-assignment-operators-runtime-semantics-evaluation">this section</a> of the specification, which explicitly only sets the function name if the <em>IsIdentifierRef</em> of the <em>LeftHandSideExpression</em> is true (which apparently <a href="http://www.ecma-international.org/ecma-262/7.0/index.html#sec-static-semantics-static-semantics-isidentifierref">it isn't</a> for property references).</p>
  
  <p>So reiterating from above: Why not? Surely there must be a <em>specific</em> reason it was not desirable/possible. What was it?</p>