[Issue 7177] $ should forward to length by default

[d-bugmail at puremagic.com]

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



--- Comment #36 from Steven Schveighoffer <schveiguy at yahoo.com> 2013-03-21 19:42:41 PDT ---
(In reply to comment #33)
> 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.

And it probably would function.  You don't need a trait to write code that
expects $ to work.  And even if $ DID work, it may not work the way you expect,
that is, length and $ may not be equivalent.  In other words, it's impossible
to write a trait that says "$ must be equivalent to length."

It is OK with me, however, if you want to say that a RA range with hasLength
requires $ to function as length.

I just don't want the compiler to assume that $ means length for all types.

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

r[0..$] is equivalent to r[], there is no need to require it.

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

Changing the trait will break existing code, making the assumption will break
existing code.  There is nothing that can be done I can think of that wouldn't
break existing code.

So if you have to break existing code, break phobos code that can be fixed in
the same commit!

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

That is fine, as I've already said.  If you want to change the trait, go right
ahead!

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

Doing it in the compiler is not correct, the compiler shouldn't care what
opDollar means.  Otherwise, it should just make $ mean length.  Ranges are a
phobos concept.  If you want to define it for isRandomAccessRange + hasLength
only, I think that is fair too (I'm assuming here we can change the compiler to
allow adding opDollar using UFCS).

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