Hi Nicholas, sorry for the tardy reply. I did propose NoSuchProperty to 
Ecma TC39 today. To recap:

// Library code starts here.

const NoSuchProperty = Proxy(Object.prototype, {
   // uncomment for nasty Firefox bug workaround:
   // has: function(target, name) { return true; },
   get: function(target, name, receiver) {
     if (name in Object.prototype) {
       return Reflect.get(Object.prototype, name, receiver);
     }
     throw new TypeError(name + " is not a defined property");
   }
});

function NoSuchPropertyClass() {}
NoSuchPropertyClass.prototype = NoSuchProperty;

// End library code.
// Your client code starts here.

class MySaferClass extends NoSuchPropertyClass {
   ...
}

The library code is self-hosted based on ES6 Proxies and Reflect.

The committee reaction was to let this be put in popular libraries, in 
forms to be polished based on actual developer experience, and then we 
can standardize once there is a clear winner and strong adoption.

Hope this is survivable. I argued we should shortcut to reduce the 
burden on the ecosystem but (as I've argued many times) TC39 believes we 
are least capable compared to the wider ecosystem (github, etc.) in 
designing, user-testing, polishing, and finalizing APIs. We can do final 
polish and formal specification, for sure. Y'all should do the hard 
part, not because we are lazy but because you are many, closer to your 
problem domains and use-cases, and collectively wiser about the details.

/be

Brendan Eich wrote:
> Just FTR, I'll put a ratioanlized ES7 proposal on the agenda for the 
> July TC39 meeting, as per
>
> https://twitter.com/BrendanEich/status/475067783282057216
>
> Thanks to Nicholas for the suggestion!
>
> /be
>
> Brendan Eich wrote:
>> Nicholas C. Zakas wrote:
>>> It can be done with Proxy, but that kind of sucks because I always 
>>> need to go through the extra step of creating the Proxy for each 
>>> object and passing around the Proxy instead. To me, this is similar 
>>> to setting a property to be readonly in strict mode, except its 
>>> writeonly (or rather, write-first).
>>
>> What about the code I showed, which shows a singleton being spliced 
>> high on many objects' prototype chains to handle the missing property 
>> throw?
>>
>> js> var NoSuchProperty = Proxy({}, {
>>   has: function(target, name) { return true; },
>>   get: function(target, name, receiver) {
>>     if (name in Object.prototype) {
>>       return Reflect.get(Object.prototype, name, receiver);
>>     }
>>     throw new TypeError(name + " is not a defined property");
>>   }
>> });
>> js> var obj = Object.create(NoSuchProperty)
>> js> obj.foo = 42
>> 42
>> js> obj.foo
>> 42
>> js> obj.bar
>> /tmp/p.js:7:4 TypeError: bar is not a defined property
>>
>> You could avoid Object.create by assigning to a 
>> Constructor.prototype, or hacking with __proto__, of course.
>>
>> /be
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140923/d2a16640/attachment.html>

sorry for the tardy reply. I did propose NoSuchProperty to 
Ecma TC39 today. To recap:

```js
// Library code starts here.

const NoSuchProperty = Proxy(Object.prototype, {
   // uncomment for nasty Firefox bug workaround:
   // has: function(target, name) { return true; },
   get: function(target, name, receiver) {
     if (name in Object.prototype) {
       return Reflect.get(Object.prototype, name, receiver);
     }
     throw new TypeError(name + " is not a defined property");
   }
});

function NoSuchPropertyClass() {}
NoSuchPropertyClass.prototype = NoSuchProperty;

// End library code.
// Your client code starts here.

class MySaferClass extends NoSuchPropertyClass {
   ...
}
```

The library code is self-hosted based on ES6 Proxies and Reflect.

The committee reaction was to let this be put in popular libraries, in 
forms to be polished based on actual developer experience, and then we 
can standardize once there is a clear winner and strong adoption.

Hope this is survivable. I argued we should shortcut to reduce the 
burden on the ecosystem but (as I've argued many times) TC39 believes we 
are least capable compared to the wider ecosystem (github, etc.) in 
designing, user-testing, polishing, and finalizing APIs. We can do final 
polish and formal specification, for sure. Y'all should do the hard 
part, not because we are lazy but because you are many, closer to your 
problem domains and use-cases, and collectively wiser about the details.