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.
