Dealing with Autodecode

Adam D. Ruppe via Digitalmars-d digitalmars-d at puremagic.com
Tue May 31 18:36:43 PDT 2016


On Wednesday, 1 June 2016 at 00:46:04 UTC, Walter Bright wrote:
> It is not practical to just delete or deprecate autodecode

Yes, it is.

We need to stop holding on to the mistakes of the past. 9 of 10 
dentists agree that autodecoding is a mistake. Not just WAS a 
mistake, IS a mistake. It has ongoing cost. If we don't fix our 
attitude about these problems, we are going to turn into that 
very demon we despise, yea, even the next C++!

And that's not a good thing.

> To that end, and this will be an incremental process:

I have a better one, that we discussed on IRC last night:

1) put the string overloads for front and popFront on a version 
switch:

version(string_migration)
deprecated void popFront(T)(ref T t) if(isSomeString!T) {
   static assert(0, "this is crap, fix your code.");
}
else
deprecated("use -versionstring_migration to fix your buggy code, 
would you like to know more?")
/* existing popFront here */


At the same time, make sure the various byWhatever functions and 
structs are easily available.

Our preliminary investigation found about 130 places in Phobos 
that need to be changed. That's not hard to fix! The static 
assert(0) version tells you the top-level call that triggered it. 
You go there, you add .byDchar or whatever, and recompile, it 
just works, migration achieved. Or better yet, you think about 
your code and fix it properly, boom, code quality improved.

D USERS **WANT** BREAKING CHANGES THAT INCREASE OVERALL CODE 
QUALITY WITH A SIMPLE MIGRATION PATH!!!!!!!!!!!!!!!!!!!!


2) After a while, we swap the version conditions, so opting into 
it preserves the old behavior for a while.

3) A wee bit longer, we exterminate all this autodecoding crap 
and enjoy Phobos being a smaller, more efficient library.



More information about the Digitalmars-d mailing list