Skip to content
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

Subtyping relationship between stringref and stringviews #3

Open
wingo opened this issue Apr 27, 2022 · 1 comment
Open

Subtyping relationship between stringref and stringviews #3

wingo opened this issue Apr 27, 2022 · 1 comment

Comments

@wingo
Copy link
Collaborator

wingo commented Apr 27, 2022

The current document treats strings and the three stringview kinds as unrelated types. It would be more tidy if they had a subtyping relationship, somehow. Some possibilities:

  1. Stringviews are subtypes of stringref.
  2. Stringviews share a supertype.
  3. One string type per view type.
  4. Current status: unrelated types.

Related previous discussion: wingo/stringrefs#31 (comment) and following comments, and wingo/stringrefs#40.

@jakobkummerow
Copy link
Collaborator

Just to summarize my earlier comments:

I have no implementation concerns either way. In particular not against option 1: any implementation that has "slice" or "rope" or other indirect strings already has precedent for the concept of "a string subtype that's essentially a sort of view on some other string(s)".

I think the most relevant question is: is there a need to support getting from a stringview back to its underlying stringref, and if so, how do we want to express that? If we introduce stringview_* <: stringref, then getting from the former to the latter is simply an implicit upcast. If we introduce a set of stringview_*.get_stringref instructions, that would enable the same expressiveness. If we assume that stringviews are cheap to create and short-lived, then maybe there is no need to get back to the stringref. Maybe the upcoming prototyping work can shed some light on the practical requirements.

In the past, we've often followed the rule of thumb "don't introduce subtyping relations for which there is no use case". Maybe that should apply here as well (i.e. option 4 until sufficiently compelling use cases are found)?

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