What this sub-discussion of CSS `supports(..)` is reinforcing is what I said
earlier: a capability to do feature tests in a direct, efficient, and non-hacky
manner is valuable to some/many uses and use-cases, even with the recognition
that it doesn't have to *perfectly* support all conceivable
uses/use-cases/tests.
We should avoid a mindset that anything short of perfect isn't worth doing at
all. Thankfully JS doesn't have such a design principle.
A `Reflect.supports( Symbol.TCO )` test isn't perfect. It could accidentally or
intentionally lie. But it *could* be better to some audiences than having no
information. I personally would prefer to use it, even with its "risks", than
trying a long recursive loop in a `try..catch` to imply if TCO was in effect.
Nevertheless, it's the least important kind of test being advocated for here,
even though it seems to be getting all the attention. If that kind of test is a
bone of contention, it should be the easiest to drop/ignore.
Moreover, to reduce the risk of bitrot on feature lookup tables (that
`Symbol.TCO` would suffer), the `Reflect.supports( "(() => {})" )` test seems
like it would be preferable to a `Reflect.supports( Symbol.arrowFunction )`
type of test.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
