Skip to content

string.new_lossy_utf8 #55

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
annevk opened this issue Dec 2, 2022 · 1 comment
Open

string.new_lossy_utf8 #55

annevk opened this issue Dec 2, 2022 · 1 comment

Comments

@annevk
Copy link
Member

annevk commented Dec 2, 2022

It seems weird to give what's commonly the default behavior for UTF-8 decoding the longer name.

Also, I would be much more comfortable if this referenced https://encoding.spec.whatwg.org/#utf-8-decode. We don't really want other decoding behavior and Unicode historically gave other options here.

@dcodeIO
Copy link
Contributor

dcodeIO commented Dec 2, 2022

Seems reasonable to drop string.new_utf8 and have string.new_utf8_lossy take its place, given that there is nothing useful one can do with a trap anyway. Perhaps, a mechanism to tell, after the fact, whether replacement was performed, would provide more useful utility, as it could be utilized to trap, warn or raise an exception?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants