Proper values on holder

[zloirock]

It looks like a more significant problem with this way of polyfilling:

[zloirock]

https://github.com/tc39/test262/blob/main/test/built-ins/JSON/parse/reviver-array-non-configurable-prop-create.js
https://github.com/tc39/test262/blob/main/test/built-ins/JSON/parse/reviver-array-non-configurable-prop-delete.js
https://github.com/tc39/test262/blob/main/test/built-ins/JSON/parse/reviver-object-non-configurable-prop-create.js
https://github.com/tc39/test262/blob/main/test/built-ins/JSON/parse/reviver-object-non-configurable-prop-delete.js

[WebReflection]

I'll have a look but to be honest this is the reason it's a ponyfill ... if you don't need or use a context you are better off with native implementation for both performance and API stability reasons, when you need a context you use this and maybe I should warn that these kind of scenario might not be fully supported because the day I need to write a JSON parser is the day this module can RIP.

I'll have a look but with very low priority, thanks regardless for letting me know.

[zloirock]

I was just trying to remember why I decided against a similar implementation -) I agree that this is an acceptable tolerance for a ponyfill. But I think this should be specified in the documentation.

[WebReflection]

I wrote something in the README: https://github.com/ungap/raw-json?tab=readme-ov-file#known-limitations-vs-core-js

I'll keep this open for a while but I don't feel like this is urgent, it's probably a won't fix but before doing that I want to take some time to think about it and not rush any decision.

Thanks again.

[WebReflection]

btw, I want to be clear it wasn't my intent to ever, even closely, imply that core-js implementation is wrong or anything, it does the right/safe thing but for my use case it was absolutely overkill ... I believe for many others just caring about BigInt, which is basically the only reason right now this proposal exist, would be just fine in reviving those without needing to satisfy all the defensive shenanigans that test265 need to cover.

I admire the specs' compliance of core-js, I don't necessarily need any of that daily, which is why @ungap exists in the first place: perf and "good enough" use cases, not surely a replacer for Babel or correctness at all costs.

[zloirock]

I understand this perfectly, it's just that after your tweets I decided to check whether it was too early for me to discard such an implementation, especially since I relied on your ideas a couple of times earlier when writing/improving polyfills -)

[benatkin]

This issue can be closed it seems, as it isn't planned to be implemented, and with the caveat @ungap/raw-json still seems quite sound as a ___ponyfill___. Maybe the README could be improved to better explain this though. I appreciate both this and core-js, each is the right tool for different jobs IMO.