util: add types.isFloat16Array()
#57879
Conversation
nodejs-github-bot
added
needs-ci
LiviaMedeiros
force-pushed
the
util-types-isfloat16array
branch
from
1d0b220 to
2096f20
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #57879 +/- ##
=======================================
Coverage 90.23% 90.24%
=======================================
Files 630 630
Lines 185688 185693 +5
Branches 36405 36402 -3
=======================================
+ Hits 167559 167578 +19
- Misses 11000 11001 +1
+ Partials 7129 7114 -15
🚀 New features to boost your workflow:
|
| @@ -3102,6 +3102,23 @@ types.isExternal(new String('foo')); // returns false | |||
| For further information on `napi_create_external`, refer to | |||
| [`napi_create_external()`][]. | |||
|
|
|||
| ### `util.types.isFloat16Array(value)` | |||
There was a problem hiding this comment.
This can be done fully on user land , why are we exposing it?
There was a problem hiding this comment.
Wouldn't it be inconsistent to not expose the 16 bit version next to all others?
There was a problem hiding this comment.
I'm not sure consistency should be enough to expand the API surface. Is there any other reasoning for adding this other than consistency?
There was a problem hiding this comment.
In the scope of this PR, the aim is on having this particular function on node:internal/util/types. It is re-exported as node:util/types as is.
There was a problem hiding this comment.
It can't be done in userland easily, though, because you'd have to extract the Symbol.toStringTag getter. Consistency is a pretty strong justification for extending any API surface, on its own merits.
| @@ -1,4 +1,5 @@ | |||
| // Flags: --experimental-vm-modules --expose-internals --allow-natives-syntax | |||
| // Flags: --experimental-vm-modules --expose-internals --allow-natives-syntax --js-float16array | |||
| // TODO(LiviaMedeiros): once `Float16Array` is unflagged in v8, remove `--js-float16array` above | |||
There was a problem hiding this comment.
I also think we shouldn't land this until this becomes stable.
There was a problem hiding this comment.
I think doing it the other way around is actually good so that the new method is available as soon as it becomes stable. It will likely not be used before that anyway.
There was a problem hiding this comment.
It is already stable, it is stage 4 – and if you meant the V8 implementation, that's really not necessary IMO, precisely because we can trust it will follow the spec.
Why? It is under runtime flag yet, but it already can be used in currently supported release lines. The worst that can happen from using it without the flag is the function returning I understand possible concern of "it is confusing for users if we provide typecheck function for something that doesn't exist without runtime flag", but I can't come up with a scenario where this would actually hurt or be misused.
On the contrary, I'd like to have it as |
|
@LiviaMedeiros minor, not patch, since it's adding something :-) |
LiviaMedeiros
added
the
semver-minor
This comment was marked as outdated.
This comment was marked as outdated.
aduh95
added
the
author ready
aduh95
added
commit-queue
nodejs-github-bot
removed
the
commit-queue
|
Landed in e61937b |
Float16Arrayis expected to become a thing in upcoming major release, and it's already available with--js-float16arrayruntime v8 flag.