It is not practical to just delete or deprecate autodecode - it is too embedded into things. What we can do, however, is stop using it ourselves and stop relying on it in the documentation, much like [] is eschewed in favor of std::vector in C++.

The way to deal with it is to replace reliance on autodecode with .byDchar (.byDchar has a bonus of not throwing an exception on invalid UTF, but using the replacement dchar instead.)

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

1. Temporarily break autodecode such that using it will cause a compile error. Then, see what breaks in Phobos and fix those to use .byDchar

2. Change examples in the documentation and the Phobos examples to use .byDchar

3. Best practices should use .byDchar, .byWchar, .byChar, .byCodeUnit when dealing with ranges/arrays of characters to make it clear what is happening.

On Wednesday, 1 June 2016 at 00:46:04 UTC, Walter Bright wrote:
> It is not practical to just delete or deprecate autodecode - it is too embedded into things.
Which Things ?
> The way to deal with it is to replace reliance on autodecode with .byDchar (.byDchar has a bonus of not throwing an exception on invalid UTF, but using the replacement dchar instead.)

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

So does this mean we intend to carry the auto-decoding wart with us into the future. And telling everyone :
"The oblivious way is broken we just have it for backwards compatibility ?"

To come back to c++ [] vs. std.vector.

The actually have valid reasons; mainly c compatibility.
To keep [] as a pointer.

I believe As of now D is still flexible enough to make a radical change.
We cannot keep putting this off!

It is only going to get harder to remove it.

On 5/31/16 8:46 PM, Walter Bright wrote:
> It is not practical to just delete or deprecate autodecode - it is too
> embedded into things. What we can do, however, is stop using it
> ourselves and stop relying on it in the documentation, much like [] is
> eschewed in favor of std::vector in C++.
>
> The way to deal with it is to replace reliance on autodecode with
> .byDchar (.byDchar has a bonus of not throwing an exception on invalid
> UTF, but using the replacement dchar instead.)
>
> To that end, and this will be an incremental process:
>
> 1. Temporarily break autodecode such that using it will cause a compile
> error. Then, see what breaks in Phobos and fix those to use .byDchar
>
> 2. Change examples in the documentation and the Phobos examples to use
> .byDchar
>
> 3. Best practices should use .byDchar, .byWchar, .byChar, .byCodeUnit
> when dealing with ranges/arrays of characters to make it clear what is
> happening.

I gotta be honest, if the end of this tunnel doesn't have a char[] array which acts like an array in all circumstances, I see little point in changing anything.

-Steve

On 5/31/2016 5:56 PM, Stefan Koch wrote:
> It is only going to get harder to remove it.

Removing it from Phobos and adjusting the documentation as I suggested is the way forward regardless. If we can't get that done, how can we tell our users they have to do the same to their code?

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.

On Tuesday, May 31, 2016 17:46:04 Walter Bright via Digitalmars-d wrote:
> It is not practical to just delete or deprecate autodecode - it is too embedded into things. What we can do, however, is stop using it ourselves and stop relying on it in the documentation, much like [] is eschewed in favor of std::vector in C++.
>
> The way to deal with it is to replace reliance on autodecode with .byDchar (.byDchar has a bonus of not throwing an exception on invalid UTF, but using the replacement dchar instead.)
>
> To that end, and this will be an incremental process:
>
> 1. Temporarily break autodecode such that using it will cause a compile error. Then, see what breaks in Phobos and fix those to use .byDchar
>
> 2. Change examples in the documentation and the Phobos examples to use .byDchar
>
> 3. Best practices should use .byDchar, .byWchar, .byChar, .byCodeUnit when dealing with ranges/arrays of characters to make it clear what is happening.

The other critical thing is to make sure that Phobos in general works with byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started trying to use byCodeUnit instead of naked strings, I ran into this:

https://issues.dlang.org/show_bug.cgi?id=15800

But once Phobos no longer relies on autodecoding except maybe in places where we can't actually excise it completely without breaking code (and hopefully there are none of those), then we can look at how feasible the full removal of auto-decoding really is. IMHO, leaving it in is a _huge_ piece of technical debt that we don't want and probably can't afford, so I really don't think that we should just assume that we can't remove it due to the breakage that it would cause. But we definitely have work to do before we can have Phobos in a state where it's reasonable to even make an attempt. byCodeUnit and friends were a good start, but we need to make it so that they're treated as first-class citizens, and they're not right now.

- Jonathan M Davis

On 5/31/2016 6:36 PM, Adam D. Ruppe wrote:
> Our preliminary investigation found about 130 places in Phobos that need to be
> changed. That's not hard to fix!

PRs please!

On 05/31/2016 09:36 PM, Adam D. Ruppe wrote:
>
> 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 */
>

I vote we use Adam's exact verbiage, too! :)

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

Yes. This. If I wanted an endless bucket of baggage, I'd have stuck with C++.

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

Yay! Profit!

On 5/31/2016 7:28 PM, Jonathan M Davis via Digitalmars-d wrote:
> The other critical thing is to make sure that Phobos in general works with
> byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started
> trying to use byCodeUnit instead of naked strings, I ran into this:
>
> https://issues.dlang.org/show_bug.cgi?id=15800

That was posted 3 months ago. No PR to fix it (though it likely is an easy fix). If we can't get these things fixed in Phobos, how can we tell everyone else to fix their code?

On 5/31/2016 7:40 PM, Walter Bright via Digitalmars-d wrote:
> On 5/31/2016 7:28 PM, Jonathan M Davis via Digitalmars-d wrote:
>> The other critical thing is to make sure that Phobos in general works
>> with
>> byDChar, byCodeUnit, etc. For instance, pretty much as soon as I started
>> trying to use byCodeUnit instead of naked strings, I ran into this:
>>
>> https://issues.dlang.org/show_bug.cgi?id=15800
>
> That was posted 3 months ago. No PR to fix it (though it likely is an
> easy fix). If we can't get these things fixed in Phobos, how can we tell
> everyone else to fix their code?

I hope that wasn't a serious question.  The answer is trivial.  The rate of incoming bug reports exceeds the rate of bug fixing which exceeds the rate of fix pulling.  Has since about the dawn of time.