Breaking backwards compatiblity

[deadalnix]

Le 10/03/2012 00:24, Jonathan M Davis a écrit :
> On Friday, March 09, 2012 15:14:39 H. S. Teoh wrote:
>> On Fri, Mar 09, 2012 at 11:46:24PM +0100, Alex Rønne Petersen wrote:
>>> On 09-03-2012 23:32, Walter Bright wrote:
>>>> This statement is from Linus Torvalds about breaking binary
>>>> compatibility:
>>>>
>>>> https://lkml.org/lkml/2012/3/8/495
>>>>
>>>> While I don't think we need to worry so much at the moment about
>>>> breaking binary compatibility with new D releases, we do have a big
>>>> problem with breaking source code compatibility.
>>>>
>>>> This is why we need to have a VERY high bar for breaking changes.
>>>
>>> If we want to start being able to avoid breaking changes, we
>>> *really* need to finally deprecate the stuff that's been slated for
>>> deprecation for ages...
>>
>> [...]
>>
>> Does that include std.stdio and std.stream? When are we expecting std.io
>> to be ready?
>>
>> IMHO, this is one major change that needs to happen sooner rather than
>> later. The current lack of interoperability between std.stdio and
>> std.stream is a big detraction from Phobos' overall quality.
>
> Note that he didn't say that we should _never_ make breaking changes but
> rather that we need to have a very high bar for making such changes. In
> particular, it's stuff like renaming functions without changing functionality
> that he's against.
>

Just about that, having a consistent naming convention is an issue of 
first importance. In the given topic, I did argue for some convention, 
but, let's look at the larger picture and how it relate to this topic. 
Whatever the naming convention is, it mandatory to have one.

So at some point, renaming stuff are going to happen, or phobos will 
become completely opaque when growing.

Renaming just one function isn't important enough to justify to break 
compatibility. Having a consistent naming convention is.