http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #20 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-21 09:11:43 PDT ---
(In reply to comment #18)
> > That's a strong case. If compiler tries to translate $ to length automatically, library AA implementation will become impossible.
> 
> That's not a problem at all. As long as the logic is that length is aliased to opDollar as long as opDollar isn't defined, then it won't break anything. Anything that needs to define opDollar differently will define opDollar, and for the rest, if they define length, then it gets aliased to opDollar. I really don't see the problem with that. And without this, requiring opDollar with hasSlicing will break tons of code.

The point of the AA example is that opDollar should be illegal, not that it should map to something else.

I don't think we need to require opDollar with hasSlicing, why would you think that?

(In reply to comment #19)
> Note though that opDollar would *fallback* to length if you did not implement opDollar. You are still free to implement your own opDollar if you wish, so your DCollections would still be fine.

My point is that I have to opt out of that behavior.  This means it breaks my current code.

> No need! Please don't close it quite yet. A simple "@disable opDollar();" or
> "private opDollar();" should shut down this problem.

This is a good thing to bring up, but I don't really understand why opDollar needs to be implemented by default.  It's only valid inside indexers, and only makes sense for indexes that are integers, begin at 0, and end at .length. Isn't that a lot of assumptions to make for opIndex, which can take any type of argument, and whose domain space can mean anything?  We can prove that a type has indexing, that it has length, even possibly that it's indexer takes the same type as length returns, but I think it's too assuming to guess at the domain space of the index.

Why is it so bad to explicitly alias opDollar to length?  It seems we are using anecdotal evidence (phobos requires a few aliases) to apply to all code in existence and that ever will exist.  An alias consumes NO code space, it's free.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #21 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-21 09:16:14 PDT ---
(In reply to comment #20)
> My point is that I have to opt out of that behavior.  This means it breaks my current code.

To expand on this point, I would say implementing opDollar by default to mean .length should be semantically correct in all existing code that defines indexing and length.  If not (and I think I've shown that it's not always correct), it should not be done.  It breaks too much existing code otherwise. The gain is so little since aliasing already works.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #22 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-03-21 09:22:30 PDT ---
> I don't think we need to require opDollar with hasSlicing, why would you think that?

Because if you don't, then you can never use $ when slicing a range. And really, isRandomAccessRange should require that $ work with finite ranges for the same reason. As it stands, you pretty much can't use $ in generic code. It's only good for arrays, because you can't count on it working for anything else. The appropriate range templates must be able to require them for us to be able to use them, and if we change them to require opDollar without this enhancement request, then it's going to break a lot of code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #23 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-03-21 09:55:37 PDT ---
If we forgo this enhancement request, then we have two choices with regards to ranges and $:

1. Never be able to use $ with ranges, because none of the range traits check for it.

2. Warn people that we're going to soon require opDollar for random-access ranges and ranges with slicing and then change isRandomAccessRange and hasSlicing accordingly (at which point, there's bound to be a fair bit of code which will break).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #24 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-21 10:14:53 PDT ---
(In reply to comment #22)
> Because if you don't, then you can never use $ when slicing a range.

This is extreme.  You certainly CAN use $ with ranges that support $.

> And really, isRandomAccessRange should require that $ work with finite ranges for
> the same reason. As it stands, you pretty much can't use $ in generic code.
> It's only good for arrays, because you can't count on it working for anything
> else.

Yes you can, it just requires the range supports $.  Define supportsDollar trait.  Done.

> The appropriate range templates must be able to require them for us to be able to use them, and if we change them to require opDollar without this enhancement request, then it's going to break a lot of code.

Then don't change them.  Requiring $ is as simple as defining a trait that checks for $ support.  There is no reason slicing has to be predicated on having an end point.  And having an end point does not require having a length (see strings) and is not necessarily an integer value equivalent to the length.

If, for example, we add requiring $ for isRandomAccessRange, and then have a function that requires a random access range but doesn't use $, what is the benefit of doing that?  Either you need $ or you don't, and that is quantifiable with a separate trait.  Support for slicing or indexing is a precondition for having $ but $ is not required in order to slice or index.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #25 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-03-21 10:23:01 PDT ---
I really don't think that it makes sense to define ranges with slicing which don't have opDollar or finite random-access ranges which don't have opDollar. And having hasOpDollar or supportsOpDollar just complicates ranges even further. I expect that the main reason that opDollar wasn't required in the first place was that it didn't even work until recently (though it may also have simply been forgotten).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #26 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-21 10:47:03 PDT ---
(In reply to comment #25)
> I really don't think that it makes sense to define ranges with slicing which don't have opDollar or finite random-access ranges which don't have opDollar.

Then why is this necessary?  If it only makes sense to define opDollar, then it will be defined, and you can use it.

> And having hasOpDollar or supportsOpDollar just complicates ranges even further.

What?  How does it do anything to make ranges more complex?  If anything, adding it to isRandomAccessRange makes them more complex, because now ranges that previously satisfied that trait may now not satisfy it.  Defining a new trait does not make anything more complex, nothing is required to implement a new trait, because nothing currently uses that trait.  No more changes are required to satisfy a new hasOpDollar trait than are required to satisfy an isRandomAccessRange trait that now requires opDollar.  In fact the same code is required.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #27 from Jonathan M Davis <jmdavisProg@gmx.com> 2013-03-21 11:14:37 PDT ---
> How does it do anything to make ranges more complex?

Because it makes yet another thing that range-based functions must test for. We arguably have too many such traits already. The _only_ reason I see to not require that opDollar work with ranges which have slicing and finite random-access ranges is the fact that the change will break code. IMHO, everything else about it is exactly the right thing to do.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #28 from monarchdodra@gmail.com 2013-03-21 11:22:48 PDT ---
(In reply to comment #27)
> > How does it do anything to make ranges more complex?
> 
> Because it makes yet another thing that range-based functions must test for. We arguably have too many such traits already. The _only_ reason I see to not require that opDollar work with ranges which have slicing and finite random-access ranges is the fact that the change will break code. IMHO, everything else about it is exactly the right thing to do.

Yeah, exactly what he said. Having yet another trait means:
a) Don't test the trait and ignore opDollar.
b) Test the trait and fork the code even more.

Neither is satisfactory. Requiring RA and slicing to support $ is just what makes sense and is natural. Making it "yet another trait" would be wrong. Just... wrong.

What we are trying to do is:
a) Not break code by adding more to the requirements.
b) Provide an external solution for ranges that don't define opDollar (because
for a range, defining opDollar as an alias of length IS natural).

And as long as we don't have this, $ is just as good as useless in generic code. The only place I know of where we use it is for popFrontN, and even then we jump through hoops to get it to work.

Getting this ER to work, in one way or another, is very important for the natural and generic usage of ranges. Right around now, I'm kind of wishing I had kept my mouth shut, because I too have been waiting for this for a while :/

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=7177



--- Comment #29 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-03-21 12:47:14 PDT ---
(In reply to comment #28)
> Yeah, exactly what he said. Having yet another trait means: a) Don't test the trait and ignore opDollar.

By your own definition (1. we don't check for it, and 2. you can't write generic code with $), that is exactly what is done now.

> b) Test the trait and fork the code even more.

Huh?  If your algorithm requires opDollar, use it.  If not, then it didn't exist before.  Where is the forking?

I looked at isRandomAccessRange.  It can be true if the range is infinite, which most likely do NOT define $.  If that is the case, how can generic code use $ simply if isRandomAccessRange is true?

> What we are trying to do is:
> a) Not break code by adding more to the requirements.

Wait, I thought we are adding opDollar to the requirements?

> b) Provide an external solution for ranges that don't define opDollar (because
> for a range, defining opDollar as an alias of length IS natural).

As I previously stated, I don't have a problem with this, as long as it only applies to ranges you define, and NOT ranges or types where it makes no sense.

1. opDollar is NOT equivalent to length in all cases.  Therefore, making it
equivalent by default BY DEFINITION breaks existing code that purposely defines
length and purposely omits opDollar.
2. Adding opDollar requirements to range traits requires all existing ranges
that could define opDollar DO define opDollar.
3. You wish to avoid immediate breakage of code that has not yet implemented
opDollar but satisfies current implementation of said traits.

So in other words your goal is to break existing code so other existing code doesn't break?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------