API changing, possible low lying fruit, random thought

[Daniel Keep]

janderson wrote:
> Just taking about one aspect, I suppose the deprecated could be changed
> to something like:
> 
> deprecated("message")
> {
>     void foo();
> }
> auto_update(inout string codeinerror)
> {
>     //code in here
>     string.replace(codeinerror, "foo()", "bar()");
> }
> 
> And when D compiled (or something) it would ask at each one... "This has
> been depreciated do you want to apply this update."
> 
> I still think thats nasty and probably wouldn't be worth the effort
> unless you have one of those purposely slow moving projects (like stl or
> something).
> 
> -Joel

That doesn't really seem like D's job, to be honest.

I think what we should do instead is to build a standardised set of code
tools for D.  Look at it like this: if there were one or two de facto
standard refactoring tools (like how bud and rebuild are the de facto
standard build tools for D), then you could fix this problem by
releasing semantic patches.

New, incompatible library release?  Release a set of scripts that use
these refactoring tools to make the changes safely and correctly.  That
way, we don't end up polluting the language with things it probably
shouldn't have.

Plus, I imagine it would be quite the selling point.

	-- Daniel

-- 
int getRandomNumber()
{
    return 4; // chosen by fair dice roll.
              // guaranteed to be random.
}

http://xkcd.com/

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D
i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/