[Issue 7177] $ should forward to length by default

d-bugmail at puremagic.com d-bugmail at puremagic.com
Sun Mar 31 10:21:23 PDT 2013


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



--- Comment #56 from Kenji Hara <k.hara.pg at gmail.com> 2013-03-31 10:21:20 PDT ---
(In reply to comment #55)
> @Kenji: I'm a bit unclear on your view on this. You mention you'd prefer a
> library solution but your pull request seems to go for a in-compiler solution.

As Steven already mentioned in comment#14, automatically forwarding from $ to
'length' would break user-defined containers.

The fact clearly represents that we cannot always regard $ as "length".
Indeed, it is true in built-in arrays and range concept, but isn't true in
associative arrays and some user-defined containers. So I think that this
enhancement has a bias toward range concept.

And, as far as possible, compiler should be a neutral.

In other words, this is just reasonable for std.range users. Most of D
programmers would use std.range, but not all.

> There is no intent to cover infinite forward ranges with default behavior.
> Again, the primary goal here should be, I think, to make code defining casual
> ranges easy and boilerplate-free. Infinite ranges or ranges that don't define
> length yet want to define slicing through to the end are comparatively rare. It
> is reasonable to request people defining those to define opDollar
> appropriately.

I don't mention that infinite range _should_ have r[n..$], rather mention that
it is possible.

> If we go for a library solution, we should define opDollar in object.d so it's
> available by default. It should look something like this (in the 1-dimensional
> case):
>
>     auto ref opDollar(R)(auto ref R r) if (is(typeof(r.length))) {
>         return r.length;
>     }

This is bad. druntime should not have things for range concept. It is a job of
std.range.

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


More information about the Digitalmars-d-bugs mailing list