Rename std.string.toStringz?

[Daniel Gibson]

Am 26.06.2011 04:02, schrieb Jonathan M Davis:
> On 2011-06-25 18:50, Daniel Gibson wrote:
>> Am 26.06.2011 03:29, schrieb Walter Bright:
>>> On 6/25/2011 5:31 PM, Jonathan M Davis wrote:
>>>> So, while the majority have indicated in the past renaming functions
>>>> in Phobos
>>>> to be properly camelcased is worth breaking code in the general case,
>>>> there is
>>>> no such consensus in this particular case, so toStringz is sticking
>>>> around.
>>>
>>> There's a large community using D that doesn't necessarily participate
>>> in ng discussions. I'd like to see more than a simple majority in order
>>> to rename existing functions (especially ones that have been around a
>>> while).
>>>
>>> Breaking existing code really, really annoys people. It drives people
>>> away from using D as "unstable" - and they'd be right.
>>>
>>> I don't think we can create a viable D community if we break existing
>>> code every month without really, really good reasons to.
>>
>> 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.
>>
>> 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.)
> 
> The current plan at the moment when it comes to deprecation is that things 
> which are deprecated will generally be labeled as scheduled for deprecation 
> for 6 months, deprecated for 6 months, and then fully removed - though the 
> exact length may vary depending on release dates and what exactly is being 
> deprecated (e.g. stuff that's been around longer is more likely to take longer 
> to remove than stuff that's changed after a single release - which hopefully 
> happens very rarely). So, code shouldn't be breaking out from under people, 
> and they'll have some time to make the necessary changes as best fits what 
> they're doing.

I think one year is pretty long for simple changes as renaming.
It may make sense when functions or whole modules are deprecated and
replaced with something else (because you have to change how your code
works), but if users just have to rename their function calls it can be
done much quicker.

> 
> As for fixing all of Phobos to be be consistent in its naming, I don't know 
> how long that that will take, but hopefully it doesn't take very long. We 
> really do need to get the changes done quickly so that we're not forcing 
> people to change their code often. 

I agree. This is what I meant with "*one* big breaking update".

> Fortunately, most of Phobos follows its own 
> naming conventions. std.string and std.ctype are the primary offenders at this 
> point, I believe. So, it probably won't take very long.

Great :-)

Cheers,
- Daniel