dcodeIO

The performance disadvantage I worry about is when chaining modules. Say for instance you have a webapp written in Rust, a form validator written in AssemblyScript, a RegEx engine written...

I do agree that the current state of IT is based on a clever idea, I'd just not agree that it leads to significant improvements in practice. For instance, as...

GC has the same problem if languages use different encodings, or somehow different object layouts, or otherwise require side-effects when constructing a string, yeah. The story just continues forever, unless...

Perhaps we can agree on the observation that Interface Types is a beautiful solution to a subset of the problem, while Universal Strings could or could not be the basis...

Perhaps a couple additional observations, given AssemblyScript's goals: **Performance:** With multiple string representations, and abstracting over them, we may end up in a situation where re-encoding happens implicitly within the...

Perhaps an improvement to universal strings could be exactly that. Make them an encoding-independent list of codepoints, with an encoding-specific Swift-like breadcrumb mechanism to enable fast random access. Hmm... Interestingly,...

I am primarily interested in evaluating what would be best for AssemblyScript at this point (i.e. switch to UTF-8), under the assumption that for instance a universal string type is...

> Note that WTF-16 and list-of-codepoints can use lift_canon and lower_canon for ASCII strings What do you mean? ASCII strings are not two-way compatible with WTF-16, unless stored with the...

I see, thank you for explaining. Providing helpers sounds good to me as well as these will be useful independently. Sorry for the noise. > "fix WTF-16 and expose strings...

This is in fact a relatively strict check atm, but it is intended. Imagine that `this.b` is a property that executes arbitrary code (accessing `this`) when accessed, then in that...