On 3/28/19 3:12 PM, H. S. Teoh wrote:
> I applaud this direction, but let's not kid ourselves
> that this is going to happen overnight.

Or at all. The entire effort would require three strong like-minded engineers, and I don't know them.

On Thursday, 28 March 2019 at 20:14:19 UTC, Andrei Alexandrescu wrote:
> On 3/28/19 3:12 PM, H. S. Teoh wrote:
>> I applaud this direction, but let's not kid ourselves
>> that this is going to happen overnight.
>
> Or at all. The entire effort would require three strong like-minded engineers, and I don't know them.

Can't we crowd-found this initiative? Also, if we lay out the rough ground lines and draft, the community could pitch in and it wouldn't necessarily be a one man's mission.
Divide et impera!

On 28.03.19 21:05, Andrei Alexandrescu wrote:
> This is a sign things have gotten off the rail. Assignment should be accessible and have obvious semantics.

Let's get rid of RefRange.opAssign then. Then assignment of RefRange has obvious semantics. RefRange.opAssign is not needed for RefRange to be useful.

[...]
> RefRange is a cancer.
> 
> Changing all data structures and algorithms to support it is the cancer going into metastasis.

Again, no one here is arguing for "changing all data structures and algorithms".

> We must excise the cancerous tissue.

We can cut out the bad parts, but leave the useful core of RefRange intact, can't we?

The useful core is: a range that wraps a pointer to another range in order to achieve reference semantics. Often, a pointer to a range is already a range, but not always. E.g., `int[]*` is not a range.

On 3/28/2019 4:02 AM, ag0aep6g wrote:
> If you want things to go your way, consider answering when someone asks for direction.

I simply cannot keep a finger on everything that is happening, and have to rely on delegating. This one caught my eye because I had just finished making those ranges DIP1000 compatible, and then some large changes to them followed right afterwards, and I thought they might be related.

On 3/28/2019 5:37 AM, Andrei Alexandrescu wrote:
> The conclusion is not to operate such changes everywhere (i.e. reason by analogy). The right conclusion is that save() is unnecessarily general and underspecified.

I've opined that `save()` should be implemented using copy construction, not assignment.

On 3/28/2019 11:48 AM, ag0aep6g wrote:
> So until new Phobos materializes some more, I'd appreciate if we could fix issue 18657 one way or the other in old Phobos.

1. deprecate RefRange

2. resolve https://issues.dlang.org/show_bug.cgi?id=18657 as "wont fix"

3. revert the recent changes to support RefRange, do it now before it gets released

On 3/28/2019 12:09 PM, Andrei Alexandrescu wrote:
> It does happen, and has happened several times in my lifetime, that an entire community is missing an important point. It seems we missed the point that change is not what we need... it's addition.

Reminds me of:

https://github.com/dlang/undeaD

That library turned out to be necessary because some old software of mine used them and there was no reasonable migration path to the newer modules.

On 3/28/2019 12:19 PM, H. S. Teoh wrote:
> But if that's the case, the stuff in maintenance mode should at least
> receive maintenance fixes of the kind being proposed for RefRange?

Don't need those fixes because it never worked. Maintenance fixes would be when language changes break the library (such as the library work I did to get DIP1000 to work).

On Thu, Mar 28, 2019 at 08:25:10PM +0000, Seb via Digitalmars-d wrote:
> On Thursday, 28 March 2019 at 20:14:19 UTC, Andrei Alexandrescu wrote:
> > On 3/28/19 3:12 PM, H. S. Teoh wrote:
> > > I applaud this direction, but let's not kid ourselves
> > > that this is going to happen overnight.
> > 
> > Or at all. The entire effort would require three strong like-minded engineers, and I don't know them.

I'd like to see this effort happen, one way or another.  Couldn't you or somebody you trust come up with a design of the core principles and a rough draft, then the rest of the community can flesh it out?  It doesn't have to be someone working on it full-time.

Also, it could be designed to be backwards-compatible with the current Phobos where this wouldn't compromise the new design, so that it could be done piecemeal instead of a one-shot effort.  Doing it piecemeal makes it much more likely to succeed, IMO.  For example, you could design a std.v2.range.primitives with the new range API (without .save) and have the community test-drive that. Then once that's solid, add other pieces to it like std.v2.range, std.v2.algorithm, etc..  At each stage you have a minimum viable product that can be used for some limited scope of the full anticipated functionality, rather than trying to chew off the entire thing in one go and finding yourself choking on on overly-large project scope.


> Can't we crowd-found this initiative? Also, if we lay out the rough ground lines and draft, the community could pitch in and it wouldn't necessarily be a one man's mission.  Divide et impera!

+1.


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.

On 28.03.19 22:33, Walter Bright wrote:
> This one caught my eye because I had just finished making those ranges DIP1000 compatible, and then some large changes to them followed right afterwards, and I thought they might be related.

I don't mind you being against those changes, but the changes so far are hardly "large". Ignoring the tests, both my PRs combined add meager 20 lines. And that's for seven bug fixes.

By the way, you recently made changes to `save` methods in std.utf:

https://github.com/dlang/phobos/pull/6900
https://github.com/dlang/phobos/pull/6903

I'm not sure why you made those, but they touch the same kind of code as my PRs, and they actually fix the issue I was fixing, too. Are you planning on applying that pattern to all of Phobos, or just std.utf for some reason?

If you're going for all of Phobos, you might end up fixing issue 18657 as a side effect. But removing RefRange.opAssign would still be nice, because it's just weird.