On Thursday, 8 March 2018 at 17:14:16 UTC, Jonathan M Davis wrote:
On Thursday, March 08, 2018 16:34:11 Guillaume Piolat via
Digitalmars-d wrote:
On Wednesday, 7 March 2018 at 13:24:25 UTC, Jonathan M Davis
wrote:
> On Wednesday, March 07, 2018 12:53:16 Guillaume Piolat via
>
> Digitalmars-d wrote:
>> On Wednesday, 7 March 2018 at 06:00:30 UTC, Taylor
>> Hillegeist
>>
>> wrote:
>> > That way the breaking change was easily fixable, and the
>> > mistakes of the past not forever. Is it just the cost of
>> > maintenance?
>>
>> auto-decoding problem was mostly that it couldn't be @nogc
>> since throwing, but with further releases exception
>> throwing will get @nogc. So it's getting fixed.
>
> I'd actually argue that that's the lesser of the problems
> with auto-decoding. The big problem is that it's
> auto-decoding. Code points are almost always the wrong level
> to be operating at. The programmer needs to be in control of
> whether the code is operating on code units, code points, or
> graphemes, and because of auto-decoding, we have to
> constantly avoid using the range primitives for arrays on
> strings. Tons of range-based code has to special case for
> strings in order to work around auto-decoding. We're
> constantly fighting our own API in order to process strings
> sanely and efficiently.
I'd agree with you, hate the special casing. However it seems
to me this has been debated to death already, and that
auto-decoding was successfully advocated by Alexandrescu and
al; surviving the controversy years ago.
Most everyone who debated in favor of it early on is very much
against it now (and I'm one of them). Experience and a better
I wasn't so much asking about auto-decoding in particular more
about the mentality and methods of breaking changes.
In a way any change to the compiler is a breaking change when it
comes to the configuration.
I for one never expect code to compile on the latest compiler, It
has to be the same compiler same version for the code base to
work as expected.
At one point I envisioned every file with a header that states
the version of the compiler required for that module. A
sophisticated configuration tool could take and compile each
module with its respective version and then one could link. (this
could very well be the worst idea ever)
I'm not saying we should be quick to change... oh noo that would
be very bad. But after you set in the filth of your decisions
long and hard and are certian that it is indeed bad there should
be a plan for action and change. And when it comes to change it
should be an evolution not a revolution.
It is good avoiding the so easily accepted mentality of legacy...
Why do you do it that way? "It's because we've always done it
that way."
The reason I like D is often that driven by its community it
innovates and renovates into a language that is honestly really
fun to use. (most of the time)
