Deprecate Obsolete Encoding Functions in std.utf#5083
Deprecate Obsolete Encoding Functions in std.utf#5083DmitryOlshansky merged 1 commit intodlang:masterfrom
Conversation
| reserve(size); | ||
| foreach (c; ubuf) | ||
| buf.ptr[pos++] = c; | ||
| } |
There was a problem hiding this comment.
according to CodeCov this isn't used/covered :/
wilzbach
left a comment
wilzbach
left a comment
There was a problem hiding this comment.
This looks quite reasonable to me. However as this is a name deprecation, maybe we should have a second LGTM?
JackStouffer
force-pushed
the
toUTF-deprecation
branch
from
2f53d2c to
0a6c31b
Compare
DmitryOlshansky
left a comment
DmitryOlshansky
left a comment
There was a problem hiding this comment.
LGTM let's kill the old junk
|
Auto-merge toggled on |
|
This introduced a regression: https://issues.dlang.org/show_bug.cgi?id=17227 |
I am not sure why you consider deprecation messages as a regression. In particular if
|
@wilzbach Why haven't they been fixed for the Windows code in Phobos? I thought fixing all usage of deprecated symbols in Phobos was a hard prerequisite to deprecating anything. |
AFAICT this has never been required - otherwise the testsuite would run with |
|
Yeah but it doesn't make sense otherwise, does it? Seems antithetical to deprecate something for everyone else but not ourselves. |
|
Any reason not to enable |
Let's have a look: #5546 |
5 participants
These functions are exactly the same as
std.utf.encode. And they are quite old, originating in 2007 according to git blame. So they probably existed beforestd.utf.encode.They also return a slice over a static array, which is a Bad IdeaTM.
Doing a deprecation cycle because they are publicly accessible and were used in other parts of Phobos.