- From: Ingvar Stepanyan <notifications@github.com>
- Date: Tue, 02 Apr 2019 07:55:19 -0700
- To: whatwg/encoding <encoding@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Tuesday, 2 April 2019 14:55:41 UTC
> It's less clear that TextEncoder is the right entry point as opposed to JS strings themselves. It would be symmetrical to TextDecoder though. Even if JS gains own support for string encoding/decoding in the future, it seems useful to have this level of consistency between existing APIs in WHATWG Encoding. > because previously there has not been a use case for such detection Sure, but I think that this usecase (asking for only valid UTF-8 output) is common enough to warrant an implementation if/when API is agreed on. Firefox can use the existing SIMD-based check implementation internally, but I don't think that the actual shape of public-facing APIs should be driven by existing internal implementations... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/encoding/issues/174#issuecomment-479035042
Received on Tuesday, 2 April 2019 14:55:41 UTC