You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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: wingo/stringrefs#31 (comment) and following comments, and wingo/stringrefs#40.
The text was updated successfully, but these errors were encountered: