Host-dependent i32 cursors makes stringref not portable

[skuzmich]

This is follow-up to #11 which is closed without addressing portability concern.

Portability is one of the greatest WebAssembly features and IMHO we should strive to find portable solutions where possible.

Some of the approaches that would make strings portable:

1. Revert to stringcursor, an opaque cursor that knows about its string
   • Can internally use efficient value, for example code unit index for UTF-8, UTF-16, etc.
   • Has issues described in Can we avoid string cursors? #6
2. Specify portable i32 cursor behaviour
   • Would allow us to use i32 arithmetic instead of string.advance and string.rewind.
   • Would not work efficiently across different string representation. But we can have different string types for different hosts which would also solve issues described in What are the benefits over having a particular "WTF-16 string reference" type? #23

[lukewagner]

I very much agree with this concern. A phenomenon we've repeatedly observed on the Web platform is that any semantically-observable behavior ends up being depended upon by content, whether or not they're supposed to. Thus, as 𝑡→∞, it seems quite likely that an i32 cursor design would lead to real portability problems that would have been avoided by an opaque cursor design.

If this importability were somehow an unavoidable consequence of having an efficient string design, then that would be one thing, but iiuc, an opaque stringcursor can fully address the problem. It seems like the motivation for moving away from stringcursor was to try to simplify the proposal but as long as the complexity of stringcursor is within reason, I think portability has precedence as a general rule within WebAssembly.

Moreover, I think a great deal of the complexity of the previous stringcursor design resulted from trying to make it a reference type, which forces it to share a uniform representation with other reference types. I would suggest instead considering a design where stringcursor is its own distinct valtype unrelated by subtyping to any other type, thereby allowing stringcursor to have an unboxed fat pointer representation that can be easily optimized and avoid all the messy subtyping/nullability questions.

FWIW, I had a chat with @lars-t-hansen today where he expressed similar concerns and preferences.

[lars-t-hansen]

FWIW, I had a chat with @lars-t-hansen today where he expressed similar concerns and preferences.

Indeed, I have discussed this with @wingo in the past and still feel that an opaque value type of some sort (not a reference type) is probably the better choice, the larger API notwithstanding.

[conrad-watt]

Moreover, I think a great deal of the complexity of the previous stringcursor design resulted from trying to make it a reference type, which forces it to share a uniform representation with other reference types.

Could this be solved by dropping anyref subtyping, in the spirit of discussion here on uniform representation (WebAssembly/gc#254)?

A valtype opaque stringcursor seems a little odd to me because

1. Presumably we must forbid storing it in linear memory to avoid leaking its byte representation (also, safely loading/validating a stringcursor from linear memory seems very tough).
2. It needs to carry a reference to its associated string, in order to avoid the possibility of stringcursor values being forged via one string and used with another (allowing forgery, imo, would make stringcursor not much better than i32 for portability). I'm currently assuming this would have to mean keeping the string alive, unless there's some weakref trick that can be played?

[lukewagner]

Could this be solved by dropping anyref subtyping, in the spirit of discussion here on uniform representation (WebAssembly/gc#254)?

I'll admit to not having read most of the comments on that issue due to volume, so maybe this is what you mean, but: I think the key is not having stringcursor be a subtype of any other (word-sized) reference type, since (non-coercive) subtyping is what forces them to share a uniform (word-sized) representation.

A valtype opaque stringcursor seems a little odd to me because

It's possible we have a different understanding of what "it's own distinct valtype" means and so we're already in agreement here but I didn't mean to suggest stringcursor should be storable in linear memory (I agree that it definitely shouldn't). My understanding of reftype isn't "an opaque value that can't be stored in linear memory" but, rather, "a type participating in the non-coercive subtyping scheme that allows type parameterization implemented via uniform representation". With that understanding (which it sounds like gc#254 aims to upend), then I think we'd both agree stringcursor needs to be a non-reftype valtype that isn't storable in linear memory? Also agreed on stringcursor needing to contain a stringref and thus being represented as a pair (stored "inline" in any heap allocation and destructured into scalars when held on the stack).

[conrad-watt]

My understanding of reftype isn't "an opaque value that can't be stored in linear memory" but, rather, "a type participating in the non-coercive subtyping scheme that allows type parameterization implemented via uniform representation".

I've always thought of reftype as meaning "an opaque value which participates in the Wasm engine's GC/lifetime analysis in some way", which I think naturally fits stringcursor. I don't feel there's a hard requirement that all reftypes should have uniform representation (at one point, the reference types MVP also didn't have subtyping!), although it's the design we naturally settled into given the existing JS VM behaviour.

I'll admit to not having read most of the comments on that issue due to volume, so maybe this is what you mean, but: I think the key is not having stringcursor be a subtype of any other (word-sized) reference type, since (non-coercive) subtyping is what forces them to share a uniform (word-sized) representation.

I think people would be ok with stringcursor not being a subtype of anyref (or similar existing reftypes) if there's a clear win in allowing it to have a different representation. The debate regarding whether anyref should be a top type (which unfortunately has been raging on and off for several years at this point) was motivated in part by hypotheticals about whether externref could benefit from having a non-uniform representation. Currently anyref is its only supertype. We have already entertained dropping this subtyping relation (i.e. facilitating non-uniform representations), and held off in part because no one seemed to actually be planning to use a different representation for externref.

[lukewagner]

It's probably not useful to duplicate the "what is a reftype?" discussion here, so I won't belabor that point given that I think we agree on the basic requirements for stringcursor. My original reason for bringing this up is that, from what I understand, part of the complexity concern around stringcursor was that special (and ultimately incomplete) optimizations would be required to achieve the desired unboxed representation if stringcursor had to share the universal (word-sized) representation, and I so I just wanted to point out that we can avoid this source of complexity.

[conrad-watt]

Apologies. I guess it's somewhat up in the air whether we choose to call such a type (without anyref/dataref etc subtyping) a kind of reftype, or define some spec-level opaquetype of which existingreftypes and the new stringcursor are each one instance. It seems like that's the only thing we've actually been debating here, so sorry for the noise.

I agree with the requirements (although I've not thought deeply about the fat pointer representation, I'm assuming it would be a "good thing" for the purpose of this conversation). I made a mistake in my initial comment that might have given a wrong impression. I should have said

A non-reftype opaque stringcursor seems a little odd to me because

rather than

A valtype opaque stringcursor seems a little odd to me because

[wingo]

Hey all -- you were right, @skuzmich. After some discussions with @jakobkummerow I ended up revising the interface to not have these strange implementation-defined cursor values. Instead, you obtain a WTF-8 or WTF-16 view on a string (#36) -- obtaining that view indicates that you intend to access the string in that way, and provides a (logical) object that one can hang breadcrumbs or an eager re-encode off of. There is also a stateful iterator interface that doesn't expose cursor values. I think that addresses the issues here but more thoughts are very welcome!