A Str is a UTF-8 encoded immutable unicode string.
A StrView is a view into a Str. This type is always unboxed, and can be created as a result of a pattern match.
This distinction is useful and allows things like pattern matching on a string and binding the rest of the matched string in a local variable in an efficient way.
However it also means that we have two types for strings and for common operations like startsWith or string equality we need to convert between types manually. For example:
A
Str
is a UTF-8 encoded immutable unicode string.A
StrView
is a view into aStr
. This type is always unboxed, and can be created as a result of a pattern match.This distinction is useful and allows things like pattern matching on a string and binding the rest of the matched string in a local variable in an efficient way.
However it also means that we have two types for strings and for common operations like
startsWith
or string equality we need to convert between types manually. For example:With these definitions, if I have a
Str
and aStrView
, I have to manually convert one to the other to compare. Similarly:Since creating a
StrView
from aStr
is cheap (the other way requires allocation and copying the contents), we could use it in arguments when possible:But the
Eq
trait definitions doesn't allow this, as theother
parameter has typeT
(i.e. same type asself
).Secondly, even if we could use
StrView
somehow, having to manually convert one to the other will be annoying.Some ideas:
Generalize
Eq
trait, add a type parameter for the compared-against type.I'm not sure if it's worth making a trait as commonly used as
Eq
more complicated.Also, the problem exists in
Ord
, methods likestartsWith
etc.Have something like Rust's
Deref
with the similar implicit coercion semantics: https://doc.rust-lang.org/std/ops/trait.Deref.html#deref-coercionNot sure if this fits nicely in Fir.