Deprecated Library Functions / Methods

[deadalnix]

On Sunday, 2 December 2012 at 23:32:56 UTC, Walter Bright wrote:
> On 12/3/2012 10:13 AM, Jonathan M Davis wrote:
>> On Monday, December 03, 2012 09:25:08 Walter Bright wrote:
>>> On 12/3/2012 8:41 AM, Jonathan M Davis wrote:
>>>> Regardless, there's some stuff that's already been 
>>>> deprecated which
>>>> probably should be outright removed at some point here (e.g. 
>>>> the
>>>> deprecated functions in std.string which don't follow the 
>>>> correct naming
>>>> conventions),
>>>
>>> I do not see a compelling reason to remove them. Just leave 
>>> them deprecated.
>>
>> They're clutter, and they've been deprecated for a while, 
>> which means that no
>> one has been able to use them without -d for a while. It's 
>> also trivial to fix
>> code which uses them, because they're primarily naming 
>> changes. It's just not
>> worth keeping that kind of clutter around in the library IMHO. 
>> And the
>> documentation has made it clear that they were going to be 
>> removed.
>
> This is really the crux of our disagreement. I do not see a 
> problem with leaving "clutter" around if it prevents breaking 
> existing code. It being trivial to fix user code is not good 
> enough - the fact that the user has to go back and fix stable, 
> working, debugged code is the problem that Chris is saying is 
> preventing him from using D seriously.
>
> Remove them from the documentation, ok, but leave them there. 
> It does not hurt to do so. Let them die on their own, we do not 
> need to push them out the airlock.

The thing that you'll never agree. In fact you are both right : 
user must be able to rely on D to compile their code for an 
extended period of time, and cruft must be cleaned at some point.

The 2 are really important. This is why both MUST be ensured, 
using 2 branches.

Thoses 2 goal are not reconcilable, and no discussion will come 
up with the best solution. This disagreement is a symptom of a 
bigger issue.