jakobkummerow
commented
2 years ago 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)?
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:
Related previous discussion: https://github.com/wingo/stringrefs/issues/31#issuecomment-1057848921 and following comments, and https://github.com/wingo/stringrefs/issues/40.