-
-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
Remove implicit conversions from String
, Char16String
and CharString
to data pointers.
#101293
base: master
Are you sure you want to change the base?
Remove implicit conversions from String
, Char16String
and CharString
to data pointers.
#101293
Conversation
7487048
to
72282c6
Compare
72282c6
to
a954b0f
Compare
a954b0f
to
f509141
Compare
f509141
to
ddbd8c2
Compare
ddbd8c2
to
57cf915
Compare
4687c61
to
42a3ff5
Compare
Sorry about the repeated pushes!! I should really learn to test this kinda change on my own repo to get other platforms to pass before I make a PR 🙃 |
I assume this is superseded by #101304, which include all changes from this PR. |
2a2ae23
to
e2f7611
Compare
…to data pointers. Make conversions to StrRange implicit to aid transition.
e2f7611
to
edb8339
Compare
I have reset two calls I had changed from
Yes! Although I would be happier if this PR was merged / approved first because it has some implications that are not discussed in the #101304 separately. |
This is mostly a sanity change to avoid accidental conversions leading to unexpected behavior.
I have not tested how many callers are affected (e.g.
String s = char_string
).All that are will experience a noticeable improvement of speed because
strlen
does not have to be called.Notes on implicitness
I have made conversions from
String
-likes toStrRange
implicit to aid the transition.I thought long and hard about whether I want to 'contribute' another implicit conversion to the codebase, seeing as though they are already leading to quite a lot of problems.
However, I think conversion to StrRange is one of the rare cases where it actually is warranted:
The only gotcha for this conversion is really that it may lead to ambiguous calls, and it may lead to unintentional loss of ownership. However, both are true about the
const char *
conversions, so it's an upgrade all around.Behavior changes
There are a few behavior changes that may lead to problems (though they are unlikely to). If problems are experienced somewhere, it's likely the caller should have been more explicit from the start, and should be addressed to do so.
Especially, callers will change behavior when encountering a
\0
: Instead of cutting the string short, they will add the character to the middle of the string. In terms ofUTF-32
, the new behavior is correct. Still, if unexpected behavior is observed, it should be evaluated on a case-by-case basis - most likely, the previous behavior was incorrect other behavior should be adjusted to fit.