On Sunday, April 15, 2018 12:29:17 Dmitry Olshansky via Digitalmars-d wrote:
> On Sunday, 15 April 2018 at 10:39:32 UTC, Jonathan M Davis wrote:
> > So, while I'd love to have the opportunity to sit down and
> > redesign the range API, I don't see how we really can - not and
> > actually have it implemented as part of the language or Phobos
> > anyway.
>
> Yeah, I think as surely as we can redesign postblit. Let’s not
> focus on learned helplessnes and “it’s just the way things are”.
> Recent opMove shows there is great flexibility in what can be
> done.
>
> Seriously, it’s just fixing a library design issue even if its
> use proved viral.

Replacing postblit is trivial in comparison to redesigning ranges. The worst
that's going to happen with postblit is that all postblit constructors are
going to be deprecated in favor of some other kind of constructor, which
would result in a deprecation warning for types with postblit constructors
until they've replaced one constructor with the other. As far as breaking
changes go, it shouldn't be much more complicated than renaming a function
and requiring everyone to update their code. It shouldn't even affect anyone
using types with postblit constructors except maybe if they're using
__traits(getMembers, ...) to get at __postblit or __xpostblit. It's just the
types themselves that need to be updated. In that sense, it's actually less
disruptive to replace the postblit constructor than it would be to rename a
function, because all that has to be changed is the function itself, not
every place that it gets called.

And if we get some kind of opMove solution, that wouldn't break any existing
code. It would be invisible to anything but new code that was written to use
it. That's the easiest kind of improvement.

Ranges, on the other hand, are integral to how a large percentage of Phobos
works, and a lot of existing code depends on them heavily. And unless you're
talking about simply renaming popFront to something else, changing them gets
pretty hairy. Changing ranges in any serious way risks having to essentially
fork Phobos (or at least large portions of it). Any major redesign would
almost certainly require renaming most or all of the range traits. All
functions accepting ranges would have to be rewritten. Any function
returning a range would have to either be renamed or somehow work with both
the old and new range API (and since containers use an operator rather than
a function name to provide ranges, that could make updating containers
rather interesting unless we're willing to give up on slicing being how we
get a range from a container).

We may be able to make small changes here and there, but I don't see how
anything major is possible unless we're willing to break a ton of existing
code. Now, maybe someone can come up with something clever to make some
decent improvements to what we have without doing a major redesign, but I
think that a major redesign requires effectively forking the range API,
which means either ending up with two different range APIs that everyone has
to deal with, or requiring all range-based code to eventually be updated
from one range API to another, which is an enormous change and far more than
simply swapping one function out for another.

So, if we decide that we're willing to make changes that effectively require
that almost every D program make changes that are potentially quite
invasive, then sure, we can redesign the range API. And it would be great to
be able to do that. But I have a hard time buying that such a large change
would be acceptable at this point.

- Jonathan M Davis


Reply via email to