Closed
Description
#76460 experimented with this, but it was never finished. We should figure out whether we actually want this
Pros:
&str
is nicer to work with thanSymbolStr
, e.g. avoids the need for some&
and&*
occurrences.- It would be nice to eliminate
SymbolStr
. - It avoids the lie that
SymbolStr
strings have astatic
lifetime, replacing it with a smaller lie that the strings have a lifetime tied to the lifetime of the inputSymbol
.
Cons:
- That lifetime is still a lie, and it's possible to cause crashes with this.
- The lie is less obvious in a vanilla
&str
than it is within aSymbolStr
. - We can't mark
&str
as!Send
and!Sync
.- this may be why
SymbolStr
(or what it was called previously) was introduced in the first place, because Zoxc did it together with the work on compiler parallelization.
- this may be why
- I haven't yet eliminated
SymbolStr
entirely. Theto_stable_hash_key()
is the hardest case.