On Thursday, November 29, 2018 12:54:34 PM MST 12345swordy via Digitalmars-d wrote:
> On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe
>
> wrote:
> > On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy
> >
> > wrote:
> >> You need one if you want to deprecate a language feature. There is no alternative afaik.
> >
> > autodecode is not a language feature. It is a library function that is only called by other library functions.
>
> Yet everyone here acts like it is a major deprecation, with different opinions on how to handle it.

It _is_ major. What Nicholas has proposed would break almost all string-related code in the entire D ecosystem. It would not be silent breakage, and because it involves deprecations, no one would have to update their code immediately, but a _ton_ of code would have to be updated - even code that would work just fine if we were to just switch to treating strings as ranges of code units. And given the insane number of deprecation messages that it would cause, I'm willing to bet that a _lot_ of folks would simply start compiling with the flag to get rid of deprecation messages rather than updating their code, which would make the point when the functions were actually removed rather interesting. It's quite possible that that huge disruption would be worth it given that it would allow us to get rid of autodecoding, but there's no question that it's huge. The magnitude of the breakage would dwarf anything that we've done in years.

That being said, it's still a library change, not a language change, and DIPs are for proposing language changes, not library changes. So, a DIP should not be necessary. Given the magnitude of the change and the code that it would be changing, Andrei would likely need to approve the PR, but it would still just be a PR (or set of PRs if necessary).

- Jonathan M Davis

On 11/29/18 2:54 PM, 12345swordy wrote:
> On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe wrote:
>> On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy wrote:
>>> You need one if you want to deprecate a language feature. There is no alternative afaik.
>>
>> autodecode is not a language feature. It is a library function that is only called by other library functions.
> 
> Yet everyone here acts like it is a major deprecation, with different opinions on how to handle it.

It is a major deprecation. The largest problem would be that strings all of a sudden would have an element type of char. I still think Phobos will handle this properly (or can be made to quite easily), but other code might not be so lucky.

But I don't know whether it requires a DIP or not. In any case, I'm going to try removing it and see what breaks. If the PR to "remove autodecode" from Phobos isn't that hairy, it may put a different light on what breakage may happen.

-Steve

It seems you are right, I have a feeling that this code use autodecoding:
foreach(c; someString){...}

but it seems it does not

https://run.dlang.io/is/YGgigJ

On Thu, Nov 29, 2018 at 7:45 PM Adam D. Ruppe via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 29 November 2018 at 18:33:07 UTC, 12345swordy wrote:
> > You need one if you want to deprecate a language feature. There is no alternative afaik.
>
> autodecode is not a language feature. It is a library function that is only called by other library functions.
>

On Thursday, 29 November 2018 at 21:11:20 UTC, Daniel Kozak wrote:
> It seems you are right, I have a feeling that this code use autodecoding:
> foreach(c; someString){...}
>
> but it seems it does not

Indeed, it iterates over the chars.

You can *request* decoding with

foreach(dchar c; someString) {...}

but that's not auto (nor does it use the library facility, that is actually built in)

On Thu, Nov 29, 2018 at 01:21:50PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Thursday, November 29, 2018 12:54:34 PM MST 12345swordy via Digitalmars-d wrote:
> > On Thursday, 29 November 2018 at 18:40:13 UTC, Adam D. Ruppe
[...]
> > > autodecode is not a language feature. It is a library function that is only called by other library functions.
> >
> > Yet everyone here acts like it is a major deprecation, with different opinions on how to handle it.
> 
> It _is_ major. What Nicholas has proposed would break almost all string-related code in the entire D ecosystem. It would not be silent breakage, and because it involves deprecations, no one would have to update their code immediately, but a _ton_ of code would have to be updated - even code that would work just fine if we were to just switch to treating strings as ranges of code units.

Y'know, we keep talking about how huge a breakage removing autodecoding would cause, but have we ever quantified our claim/belief?  What about this little experiment:

Since we already have CI setup to test a good number of major D codebases, how about we create a test environment (could be as simple as just a PR -- mark it "do not merge" or whatever) that removes autodecoding.  Let the CI run, and tell us just how big the actual breakage is.  Presumably, "good" D codebases also ought to have sufficient unittests that any subtle breakage caused by strings being ranges of char rather than dchar would be caught as a unittest failure rather than silently ignored.

Now, of course, the D code tested by CI is only a subset of all D code out there, but surely it should be a sufficiently generic representation of your average D code in the wild.  We could add the projects on code.dlang.org to the list, plus any other projects the forumites here might be interested to add to this experiment.  This should give us a pretty good idea of just how big of a breakage we're talking about, and what kind of issues we might face were we to actually go ahead with removing autodecoding.

Once we have this data, perhaps it would help us get off the fence about autodecoding.  It's entirely possible that the actual breakage that would be caused will actually be much less than we fear.  This experiment will help allay those unfounded fears -- or confirm them, if the scope of breakage really is as large as everyone keeps saying.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

On Thursday, 29 November 2018 at 21:21:19 UTC, H. S. Teoh wrote:
> Y'know, we keep talking about how huge a breakage removing autodecoding would cause, but have we ever quantified our claim/belief?  What about this little experiment:

Sounds like a job for https://git.ikeran.org/dhasenan/dubautotester

On Thursday, 29 November 2018 at 21:21:19 UTC, H. S. Teoh wrote:
> [snip]
>
> Since we already have CI setup to test a good number of major D codebases, how about we create a test environment (could be as simple as just a PR -- mark it "do not merge" or whatever) that removes autodecoding. ...

I was thinking the same thing...just removing the string specialized range primitives doesn't take a lot of work (I discussed a strategy above that leaves those functions but changes behavior based on a version statement).

On Thu, 29 Nov 2018 21:33:08 +0000, Paul Backus wrote:
> On Thursday, 29 November 2018 at 21:21:19 UTC, H. S. Teoh wrote:
>> Y'know, we keep talking about how huge a breakage removing autodecoding would cause, but have we ever quantified our claim/belief?  What about this little experiment:
> 
> Sounds like a job for https://git.ikeran.org/dhasenan/dubautotester

Got a patch?

On Thu, 29 Nov 2018 21:58:55 +0000, Neia Neutuladh wrote:
> On Thu, 29 Nov 2018 21:33:08 +0000, Paul Backus wrote:
>> Sounds like a job for https://git.ikeran.org/dhasenan/dubautotester
> 
> Got a patch?

By which I mean, do you have a druntime / phobos patch to test out? Because I've hacked up support for exercising experimental compilers.

On Thu, 29 Nov 2018 16:13:59 +0000, M.M. wrote:
> Could such an automated tool be done, in principle, for handling autodecode in existing code?

Yes, but it's going to be awkward. You'd need to add a std.range function like "noAutoDecode" and wrap everything that's iterated unless you can prove it's not a string or wstring.