Naming things in Phobos - std.algorithm and writefln

[Steven Schveighoffer]

On Wed, 05 Aug 2009 18:47:35 -0400, Michel Fortin  
<michel.fortin at michelf.com> wrote:

> On 2009-08-05 17:40:34 -0400, Andrei Alexandrescu  
> <SeeWebsiteForEmail at erdani.org> said:
>
>> Sergey Gromov wrote:
>>> Wed, 05 Aug 2009 17:29:11 +1000, Daniel Keep wrote:
>>>
>>>> Michel Fortin wrote:
>>>>> In std.algorithm, wouldn't it be clearer if "splitter" was called
>>>>> "splitLazily" or "splitLazy"? "splitter" is a noun, but as a function
>>>>> shouldn't it be a verb. "makeSplitter" or "toSplitter" perhaps?
>>>> This is a specious argument.
>>>>  splitter's only purpose is to return an instance of a Splitter  
>>>> struct.
>>>> You can't call it "splitLazily" or "splitLazy" because that implies  
>>>> that
>>>> the function is doing work, when it really isn't.
>>>  That's if you know how it works.
>>>  But if you just use these functions, it's not even remotely obvious  
>>> what
>>> the difference is, and the difference in naming is so subtle that many
>>> people will be doomed to forever confuse these functions, myself
>>> included.  I confuse getopt and getopts shell functions in the same  
>>> way.
>>> I simply can't remember which is which.
>>  Very true. If it weren't for backwards compatibility, I'd simply have  
>> split() do the lazy thing. Then array(split()) would do the eager thing.
>
> But then I thought D2 was about making things better without worrying  
> too much about backward compatibility. I find it dubious that we are  
> ready to do a breaking language change about how properties work, but  
> when it comes to replacing some standard library functions we can't  
> because of backward compatibility. What is the criterion for an  
> acceptable breaking changes?

About 500 more posts ;)

-Steve