Okay. I have an open pull request whose main goal is to rename various string and character functions so that they're properly camelcased (as has been discussed previous in this group): https://github.com/D-Programming- Language/phobos/pull/101
All in all, I think that the renaming in there is fairly obvious and non- controversial. However, we have the problem of std.string.toStringz. toStringz isn't properly camelcased (at least, _I_ would definitely argue that it isn't). Currently (in that pull request), I have it renamed to toStringZ (with the old version still around and scheduled to be deprecated, so no code would break immediately if it were merged in). But some have said that they consider toStringz to be properly camelcased (apparently they view stringz as a special word indicating a zero-terminated string). Another suggestion was to rename it to toCString (which is arguably much more obvious for newbies). In addition to that, we have std.utf.toUTF16z, which matches the naming scheme that toStringz has, so if we rename toStringz, we should probably rename toUTF16z as well (to toWCString?). Certainly, there's no consensus on what to do with the name of toStringz. Now, toStringz is probably one of the most heavily used string functions in Phobos. If we rename it, a _lot_ of code is going to have to be changed. So, if we rename it, we need to give it a name which most people would consider better than toStringz and worth the consistency that we gain with regards to the naming of functions in Phobos. So, the question is, should we 1. Keep toStringz as it is (as well as toUTF16z) and either consider stringz to be some sort of word unique to the D community or just admit that we're not going to camelcase it because it would break too much code to do so. 2. Just camelcase it properly and rename it to toStringZ (and probably rename toUTF16z to toUTF16Z). Code will have to be changed, but the function is still immediately recognizable to long time D programmers. 3. Rename it to toCString (probably renaming toUTF16z to something like toWCString), so it's then more recognizable to newbies, but it'll take some getting used to for everyone else (and of course require lots of code to be changed). 4. Rename toStringz to something else which is properly camelcased. I don't like leaving toStringz as it is because of its casing, but I also don't want to cause code breakage without general agreement on the replacement name. It's just too important of a function to change the name of willy-nilly. So, I'm looking to see what everyone else thinks. Thoughts? Opinions? - Jonathan M Davis
