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



--- Comment #60 from bearophile_hugs@eml.cc 2013-03-31 18:16:21 PDT ---
(In reply to comment #59)

> Yes, there is a bias - frequency. My core argument is that the vast majority of ranges simply want $ and length to mean the same thing, and very few need to have them mean different things.

I have lost part of the track of this long thread.

Adding one alias to a whole class/struct container is a really small amount of simple boilerplate code. So I think having to add it is not bad.

On the other hand in most cases such alias is desired, so it's good for it to be the default, and have some syntax (even a longish one) to disallow it in the rare cases when it's not desired.

-- 
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 #61 from timon.gehr@gmx.ch 2013-04-01 01:37:34 PDT ---
(In reply to comment #59)
> ...
> 
> Yes, there is a bias - frequency. My core argument is that the vast majority of ranges simply want $ and length to mean the same thing, and very few need to have them mean different things.

His proposal is to make it work for all ranges.

-- 
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 #62 from Andrei Alexandrescu <andrei@erdani.com> 2013-04-01 05:19:35 PDT ---
(In reply to comment #61)
> (In reply to comment #59)
> > ...
> > 
> > Yes, there is a bias - frequency. My core argument is that the vast majority of ranges simply want $ and length to mean the same thing, and very few need to have them mean different things.
> 
> His proposal is to make it work for all ranges.

Not sure I understand. It's possible I am confused. Could you please summarize what you mean giving some more context? Thanks.

-- 
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 #63 from timon.gehr@gmx.ch 2013-04-01 16:11:54 PDT ---
(In reply to comment #62)
> (In reply to comment #61)
> > (In reply to comment #59)
> > > ...
> > > 
> > > Yes, there is a bias - frequency. My core argument is that the vast majority of ranges simply want $ and length to mean the same thing, and very few need to have them mean different things.
> > 
> > His proposal is to make it work for all ranges.
> 
> Not sure I understand. It's possible I am confused. Could you please summarize what you mean giving some more context? Thanks.

Your proposal is to make opDollar refer to length whenever there is a length,

    auto ref opDollar(R)(auto ref R r) if (is(typeof(r.length))) {
        return r.length;
    }

by default allowing things like:

    int[int] x = [1:0,3:2];
    x[$]=1;

    assert(x==[1:0,2:1,3:2]);

As far as I understand it, his proposal is to restrict $ to ranges.

    auto ref opDollar(R)(auto ref R r) if (isInputRange!R && hasLength!R) {
        return r.length;
    }

std.range vs. object.d is a separate issue.

-- 
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 #64 from timon.gehr@gmx.ch 2013-04-01 16:13:22 PDT ---
(In reply to comment #63)
> ...
> 
> As far as I understand it, his proposal is to restrict $ to ranges. ...

Unlucky formulation. It should read "to restrict the default opDollar to ranges".

-- 
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 #65 from Andrei Alexandrescu <andrei@erdani.com> 2013-04-02 04:06:03 PDT ---
(In reply to comment #63)
> Your proposal is to make opDollar refer to length whenever there is a length,
> 
>     auto ref opDollar(R)(auto ref R r) if (is(typeof(r.length))) {
>         return r.length;
>     }

Well whenever there's a length and [].

> by default allowing things like:
> 
>     int[int] x = [1:0,3:2];
>     x[$]=1;
> 
>     assert(x==[1:0,2:1,3:2]);

That's not necessarily the case. Under the proposed semantics built-in hash tables would disable opDollar.

BTW disabling opDollar should mean "pass through". Consider:

    import std.stdio;

    void main(){
        int[size_t] a;
        int[] b = [ 1, 2, 3, 4, 5 ];
        a[5] = 1;
        a[2] = 2;
        writeln(b[a[a.length]]);
        writeln(b[a[b.length]]);
        writeln(b[a[$]]);
    }

This program prints "3 2 2" so the $ is transparently interpreted as the array's length. I'm not a fan of that particular behavior, but probably we need to preserve it.

> As far as I understand it, his proposal is to restrict $ to ranges.
> 
>     auto ref opDollar(R)(auto ref R r) if (isInputRange!R && hasLength!R) {
>         return r.length;
>     }
> 
> std.range vs. object.d is a separate issue.

Is that correct, Kenji? (I don't think we should mix ranges into this without
necessity.)

-- 
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 #66 from Kenji Hara <k.hara.pg@gmail.com> 2013-04-02 04:30:35 PDT ---
(In reply to comment #65)
> BTW disabling opDollar should mean "pass through". Consider:

I think it would introduce one more "special case" in operator overloading mechanism. I hate special rules.

> > As far as I understand it, his proposal is to restrict $ to ranges.
> > 
> >     auto ref opDollar(R)(auto ref R r) if (isInputRange!R && hasLength!R) {
> >         return r.length;
> >     }
> > 
> > std.range vs. object.d is a separate issue.
> 
> Is that correct, Kenji? (I don't think we should mix ranges into this without
> necessity.)

Yes. It is correct. See my experimental implementation.

> https://github.com/9rnsr/dmd/branches/fix7177alt https://github.com/9rnsr/phobos/branches/fix7177alt

https://github.com/9rnsr/phobos/commit/dd0d4c139828013c34e76acc74884341f31db298#L0R1326

-- 
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 #67 from Andrei Alexandrescu <andrei@erdani.com> 2013-04-02 07:47:20 PDT ---
(In reply to comment #66)
> (In reply to comment #65)
> > BTW disabling opDollar should mean "pass through". Consider:
> 
> I think it would introduce one more "special case" in operator overloading mechanism. I hate special rules.
> 
> > > As far as I understand it, his proposal is to restrict $ to ranges.
> > > 
> > >     auto ref opDollar(R)(auto ref R r) if (isInputRange!R && hasLength!R) {
> > >         return r.length;
> > >     }
> > > 
> > > std.range vs. object.d is a separate issue.
> > 
> > Is that correct, Kenji? (I don't think we should mix ranges into this without
> > necessity.)
> 
> Yes. It is correct. See my experimental implementation.

I agree this is a good counter-argument to my proposed approach.

> > https://github.com/9rnsr/dmd/branches/fix7177alt https://github.com/9rnsr/phobos/branches/fix7177alt
> 
> https://github.com/9rnsr/phobos/commit/dd0d4c139828013c34e76acc74884341f31db298#L0R1326

I think this is a good compromise. Unless there are other issues found by others, I agree moving forward with this. More thoughts?

-- 
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 #68 from Andrei Alexandrescu <andrei@erdani.com> 2013-04-02 07:48:14 PDT ---
(In reply to comment #67)
> (In reply to comment #66)
> > (In reply to comment #65)
> > > BTW disabling opDollar should mean "pass through". Consider:
> > 
> > I think it would introduce one more "special case" in operator overloading mechanism. I hate special rules.

I meant to insert "I agree this is a good counter-argument to my proposed approach." here!

-- 
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 #69 from monarchdodra@gmail.com 2013-04-02 08:13:42 PDT ---
(In reply to comment #67)
> (In reply to comment #66)
> > 
> > https://github.com/9rnsr/phobos/commit/dd0d4c139828013c34e76acc74884341f31db298#L0R1326
> 
> I think this is a good compromise. Unless there are other issues found by others, I agree moving forward with this. More thoughts?

So to wrap things up, both for myself or those who have lost track:

What we are finally doing is allowing opDollar (and only opDollar) to be implemented UFCS style, correct?

Then, inside std.range, we provide a "global range" opDollar function. This will mean that ranges (and only ranges) will  have $ => length? Is this correct so far? And in the special case of infinite ranges, it will convert to an empty object (Infinity)?

Sounds good to me. We'll just have to keep in mind that:
a) $ will be automatically provided *only* if the user imports std.range
(failure to import it will mean failure to use opDollar)
b) Implementations may still want to explicitly provide the alias, for "native"
opDollar: std.range.opDollar will only be "fall back" implementation.
To be frank, I'm 100% fine with that.

Other than that: Nitpick time!
1) The "Infinity" struct name is pretty vague. J.M. Davis and I have been using
the term "DollarToken" so far. Any chance we use that instead? It has the
advantage of being bound to the word "dollar". It can also be used for
non-infinite ranges that still want to exploit end slicing.
2) I think providing opDollar for InputRanges (as opposed to ForwardRange) is
better. I don't see why we'd want to go out of our way to cripple InputRanges.

That's it.

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