Rename std.string.toStringz?

[Jonathan M Davis]

On 2011-06-25 20:35, Daniel Gibson wrote:
> Am 26.06.2011 05:21, schrieb Jonathan M Davis:
> > On 2011-06-25 20:12, Daniel Gibson wrote:
> >> Am 26.06.2011 04:18, schrieb Walter Bright:
> >>> On 6/25/2011 6:50 PM, Daniel Gibson wrote:
> >>>> In the future the D community may be even larger - much larger
> >>>> hopefully. IMHO inconsistent naming in the standard lib makes D look
> >>>> unprofessional. If someone take a first look at the languages and it's
> >>>> standard lib and it looks like it's just cobbled together it may scare
> >>>> him off.
> >>> 
> >>> Perhaps you're right. But breaking his existing, working code will
> >>> scare off a lot more people.
> >> 
> >> They're already using D and thus probably already like it too much to be
> >> scared off by renaming some functions ;)
> >> 
> >>>> I agree that there shouldn't be breaking changes /all the time/, but
> >>>> I'd really like to see *one* big breaking update that fixes all
> >>>> naming inconsistencies within Phobos. (Keeping deprecated aliases for
> >>>> the old names for some releases should make the transition easier.)
> >>> 
> >>> Breaking existing code has been going on for years now. It needs to
> >>> stop.
> >> 
> >> Hmm.. it probably should. So let's stop it - *after* bringing Phobos in
> >> a (naming-wise) consistent state.
> > 
> > I generally agree with this, but stability does need to be reached soon.
> > 
> >> OTOH Phobos isn't done yet anyway (parts will be reaplaced, like
> >> std.stream and std.xml and new stuff will be added), so people shouldn't
> >> expect it to be stable yet anyway.
> > 
> > Part of the problem is that it _needs_ to become stable. Parts of it
> > aren't can't be yet, but it needs to reach that point so that people can
> > rely on it being stable. The more mature D is the less we can afford to
> > change things.
> 
> So we need to do it now.

That's why I'm doing what I'm doing now and not later. I think that we've put 
too much of it off too long.

> > And we _need_ to reach the where stuff works and doesn't change much, if
> > at all.
> > 
> > - Jonathan M Davis
> 
> I totally agree that Phobos should become stable. Especially stuff that
> is to be replaced should be replaced soon.
> AFAIK somebody is already working on the std.xml replacement, which is
> great.
> What remains to be done?
>  * std.stream (Unfortunately I don't have any time right now, else I'd
> try it myself.)
>  * std.socket? I think it's mostly ok, but it could need improvement.
> Some has already been done (see
> http://d.puremagic.com/issues/show_bug.cgi?id=5401 - why aren't Chris'
> fixes in Phobos yet? I really don't think we need a review process for
> that, it mostly fixes annoyances and shouldn't break anything), but some
> more (IPv6 and local address AF_UNIX support) needs to be done.

std.xml is being worked on, but I don't know what it's state is. std.stream 
still needs to be done (as I understand it, Andrei has plan, but nothing has 
actually been done yet). std.container still needs to be sorted out. All of 
its containers need to be classes, and currently only RedBlackTree is. We also 
need more container types in it, and Andrei is working on revamping it all to 
deal with custom allocators. I'm not sure what the state of std.socket is. It 
may need revamping. As I understand it, std.json needs revamping. There's been 
some talk of needing to redesign std.encoding due the current implementation 
being lacking. std.path is going to be revamped soon (once Lars is back from 
vacation, hopefully we can finally get his changes to it reviewed and merged 
in). Various functions in std.string still need to be revamped (particularly 
all of the functions taking patterns - there was some discussion of changing 
them all to take regexes). And then there are a number of small things 
throughout that need to be done, though I don't know how much of that is 
likely to break code. And I'm probably missing some stuff in that list. 
Fortunately, I think that most of the moving around of functions (e.g. moving 
some stuff from std.array to generalize it more) has already been done, so 
_that_ sort of breakage should generally be minimal in the future. Still, 
there are several modules which are supposed to be due for a redesign, and it 
just hasn't happened yet. And in addition to all of that, there's plenty of 
new functionality which we're going to need to get into Phobos (though since 
that shouldn't generally be breaking code, that's not a big deal in the same 
way).

So, there's still plenty to be done, and some of it is just plain taking too 
long, but I do think that a lot of Phobos is stabilizing. We really do need to 
try and get the major module redesigns done soon and get them out of the way 
however. We really can't be having modules in the state of flux that they've 
been in or be sitting there just waiting to be replaced while people use them 
in new code which is destined to be broken. I think things have been 
improving, but we need more help, and more needs to get done faster. The 
sooner that stuff is done, the sooner that Phobos can fully stabilize.

- Jonathan M Davis