Conversation
src/gleam/bit_array.gleam
Outdated
| // target due to not using the `utf8_codepoint` bit array segment type. Once | ||
| // the JavaScript target supports `utf8_codepoint` this function should be | ||
| // removed. | ||
| @target(javascript) |
There was a problem hiding this comment.
It's a shame so much is needed for JavaScript, and this introduces a new @target, which we have been working hard to remove.
How challenging would it be to have utf8_codepoint support in JavaScript? That seems like it would be a better solution.
There was a problem hiding this comment.
Bit array pattern matching in JS would need to be expanded to support dynamic sizes first, then utf_codepoint could be implemented on top of that.
I think it's reasonable to wait for that to happen, or alternatively a @target can be avoided by either using the longer JS-compatible version on both targets (it works fine on Erlang), or by implementing the JS version directly in JS as an external function.
richard-viney
force-pushed
the
bit_array_to_string_lossy
branch
2 times, most recently
from
378c5d3 to
f051874
Compare
richard-viney
force-pushed
the
bit_array_to_string_lossy
branch
from
f051874 to
26fc288
Compare
|
This PR is done but can't merge until Gleam supports Converting to draft until that's ready. |
richard-viney
force-pushed
the
bit_array_to_string_lossy
branch
from
26fc288 to
e39289b
Compare
richard-viney
force-pushed
the
bit_array_to_string_lossy
branch
from
e39289b to
26d7d90
Compare
|
oooh, compiler bug |
lpil
force-pushed
the
bit_array_to_string_lossy
branch
from
0401b98 to
55c6804
Compare
2 participants
Fixes #797.
The separate version of the function for the JavaScript target is a little bit of an eyesore, but can be removed at some future date once
utf_codepointpattern matching is supported on that target.