On Wednesday, 1 June 2016 at 22:24:49 UTC, Andrei Alexandrescu
wrote:
On 06/01/2016 06:09 PM, ZombineDev wrote:
Regardless of how different people may call it, it's not what
this
thread is about.
Yes, definitely - but then again we can't after each
invalidated claim to go "yeah well but that other point stands".
My claim was not invalidated. I just didn't want to waste time
arguing about it, because it is off topic. My point was that
foreach is a purely language construct that doesn't know about
the std.range.primitives module, therefore doesn't use it and
therefore foreach doesn't perform **auto**decoding. It does
perform explicit decoding because you need to specify a different
type of iteration variable to trigger the behavior. If the
variable type is not specified, you won't get any decoding (it
will instead iterate over the code units).
Deprecating front, popFront and empty for narrow
strings is what we are talking about here.
That will not happen. Walter and I consider the cost excessive
and the benefit too small.
On the other hand many people think that the cost of using a
language (like C++) that has accumulated excessive number of bad
design decisions and pitfalls is too high.
Keeping bad design decisions alienates existing users and
repulses new ones.
I know you are in a difficult decision making position, but
imagine telling people ten years from now:
A) For the last ten years we worked on fixing every bad design
and improving all the good ones. That's why we managed to expand
our market share/mind share 10x-100x to what we had before.
B) This strange feature you need to know about is here because we
chose comparability with old code, over building the best
language possible. The language managed to continue growing (but
not as fast as we hoped) only because of the other good features.
You should use this feature and here's a long list of things you
need to consider when avoiding it.
The majority of D users ten years from now are not yet D users.
That's the target group you need to consider. And given the
overwhelming support for fixing this problem by the existing
users, you need to reevaluate your cost vs benefit metrics.
This theme (breaking code) has come up many times before and I
think that instead of complaining about the cost, we should focus
on lower it with tooling. The problem I currently see is that
there is not enough support for building and improving tools like
dfix and leveraging them for language/std lib design process.
This has little to do with
explicit string transcoding in foreach.
It is implicit, not explicit.
I don't think anyone has a
problem with it, because it is **opt-in** and easy to change
to get the
desired behavior.
It's not opt-in.
You need to opt-in by specifying a the type of the iteration
variable and that type needs to be different than the
typeof(array[0]). That's opt-in in my book.
There is no way to tell foreach "iterate this array by
converting char to dchar by the usual language rules, no
autodecoding". You can if you e.g. use uint for the iteration
variable. Same deal as with .representation.
Again, off topic. No sane person wants automatic conversion
(bitcast) from char to dchar, because dchar gives the impression
of a fully decoded code point, which the result of such cast
would certainly not provide.
On the other hand, trying to prevent Phobos from autodecoding
without
typesystem defeating hacks like .representation is an uphill
battle
right now.
Characterizing .representation as a typesystem defeating hack
is a stretch. What memory safety issues is it introducing?
Memory safety is not the only benefit of a type system. This goal
is only a small subset of the larger goal of preventing logical
errors and allowing greater expressiveness.
You may as well invent a memory safe subset of D that works only
ubyte, ushort, uint, ulong and arrays of those types, but I don't
think anyone would want to use such language. Using
.representation in parts of your code, makes those parts like the
aforementioned language that no one wants to use.
