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
