It is the year 2020: why should I use / learn D?

[H. S. Teoh]

On Sat, Nov 24, 2018 at 10:25:23AM -0500, Steven Schveighoffer via Digitalmars-d wrote:
> On 11/23/18 6:49 PM, Walter Bright wrote:
[...]
> > Fixing autodecode will break about everything. But you don't like
> > breaking changes.
> > 
> > What do you suggest?
> 
> In fact, fixing autodecode will break very little. It will break some
> things, and I shudder to think of possible "correct" deprecation
> paths. But for the most part, code only cares about strings, and not
> the individual items inside them.
> 
> 1. foreach(x; someString) stays the same. In fact it gets better,
> because it will be more consistent with phobos
> 2. someString.front changes, breaking some code, but most of it is
> already written to deal with it. Take for example
> std.algorithm.splitter -- there are already cases to handle ranges of
> char, it will just move from auto-decoding to... intentional decoding.

Unfortunately, this will break range-based code that expect a range over
a string to return dchar. And thanks to item (3) below, this breakage
will be a *silent* one, which is the worst possible kind of breakage.
The code will still compile, but the semantics will be different from
what the code was originally expecting.  And to top it off, it will
mostly work if your code deals primarily with ASCII strings. Only the
poor end user on a foreign locale will even notice the breakage, and by
then it's far too late.

I'm all for killing autodecoding, but we need some way to inform user
code that the code needs to be updated. Silent breakage is unacceptable.
Better yet, have a tool to automatically convert the code to the new
idiom, possibly with some user intervention required but preferably none
besides "run this command to fix your code, then recompile".


> 3. Probably the WORST part is that char implicitly casts to dchar, so
> things that expect dchar will still compile with strings whose element
> types switch to char, but instead of decoding, it will promote. Where
> you will find problems is where code assumes char[].front is dchar
> instead of using the Phobos ElementType in constraints.

Yes, this is a big problem because it's a silent breakage.


> 4. The longer we wait, the worse it will be.
> 
> There is no way to fix autodecoding without breaking code. So we have
> to make that sacrifice to make progress. The most painful thing I
> think would be a possible deprecation path where you have to be
> explicit about how you want things decoded in order to avoid messages.
[...]

This isn't actually as bad as it sounds. Just make strings non-ranges
(temporarily), and require .byCodePoint or .byCodeUnit for iteration.
Then once the deprecation cycle is over and autodecoding is no more,
allow strings as ranges again. It will be painful, yes, but painful is
better than silent subtle breakage that nobody knows until it explodes
in the customer's face.


T

-- 
Bare foot: (n.) A device for locating thumb tacks on the floor.