[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

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



--- Comment #33 from monarchdodra at gmail.com 2013-03-21 14:14:50 PDT ---
(In reply to comment #29)
> (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's your point? isRandomAccessRange doesn't require length either. Does that
mean code that tests isRandomAccessRange can't use length? That's why we
usually test RA+hasLength. However, once you have an RA range that defines
length, it would make little sense for r[$ - 1] to not function.

Also, *sliceable* infinite ranges most definitely *do* define opDollar, and it
is part of the requirements we'd like to add to *isSliceable*. Heck, at one
point, it was argued that that should be the *only* requirement (int to $)

This would be breaking change, but sliceable infinite is new concept, so it
would break very little. And in this case, it would actually be a functional
upgrade.

Take a look at popFrontN's implementation for an example of how this would help
tons. I have an open pull for chunks. Making slicing work trying to work around
opDollar is a nightmare.

Having the guarantee that r[1 .. $] works means we wouldn't even have to worry
about whether or not r is finite. Or if it defines opDollar for that matter.

> > 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?

No. What we want is that if a range is finite and random access, then writing
"r[$ - 1]" should be legal. And "r[0 .. $]" should be legal for sliceables
(regardless of length).

That is the goal. We are discussing the how. One idea is to change the trait.
What we'd want is a functionality that would allow us to do this without
breaking existing code.

> > 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.

Ranges is a phobos concept we can define ourselves as we so wish. If you decide
to adhere to the interface, but do non-sense with it, that becomes _your_
problem. In regards to *ranges*, if one defines length, but not opDollar, then
it would make *0* sense for r[0 .. $] to not mean r[0 .. r.length]. If you have
a "ranges [...] where it makes no sense", then it is the range that makes no
sense.

The range may also decide to implement it's own opDollar if it so wishes. But
if it doesn't, we can do it. We do this with UFCS all the time. I don't see why
we can't do it for opDollar to, either via a global function, or compiler help.

> 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: -------