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

           Summary: $ should forward to length by default
           Product: D
           Version: D2
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: dsimcha@yahoo.com


--- Comment #0 from David Simcha <dsimcha@yahoo.com> 2011-12-28 06:54:28 PST ---
See the following pull request:

https://github.com/D-Programming-Language/phobos/pull/365

Andrei and I agree that this kind of boilerplate is unacceptable.  To get the benefits of opDollar without it, there needs to be some default behavior that forwards to .length if no explicit opDollar exists.

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


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2011-12-28 23:52:29 PST ---
The effect of this would be that people would declare 'length' instead of
'opDollar' in nearly all cases. This would mean that you declare opDollar if
and only if you want $ without defining 'length'. (or if $ should be different
to length). Is this what we want?
Is there anything in the existing language which behaves in this way? Or would
this be introducing an unprecedented funky behaviour?

(Just want to think through the implications, I'm not intrinsically opposed to
the idea).

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


Andrei Alexandrescu <andrei@metalanguage.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andrei@metalanguage.com


--- Comment #2 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-12-29 12:30:22 PST ---
I'm unclear what the best approach this is. One guiding element is that https://github.com/D-Programming-Language/phobos/pull/365 is pure boilerplate, which goes quite against the grain of D. It's also something that affects a lot of ranges (essentially all that define a length).

The way I see it, we should automate things such that 1-dimensional ranges that have a notion of "length" should define length (and opDollar should automatically work for them), and multi-dimensional ranges with more refined needs would define opDollar and also length.

-- 
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 #3 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-12-29 12:31:58 PST ---
Let me add that it's not impossible there are ranges that do have multi-dimensional slicing but possibly no notion of "length". Sparse matrices come to mind.

-- 
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 #4 from Don <clugdbug@yahoo.com.au> 2011-12-29 13:49:15 PST ---
(In reply to comment #3)
> Let me add that it's not impossible there are ranges that do have multi-dimensional slicing but possibly no notion of "length". Sparse matrices come to mind.

Yes. Another difference is that length is generally an integer. opDollar doesn't need to be, it could be any object. It can also be cheap to calculate opDollar but expensive to determine length.

I guess the question is, for what fraction of use cases will opDollar and length coincide?

It seems to be true for most ranges, which is interesting because they didn't even exist when this feature was first implemented -- it was designed for matrices -- yet they're now shaping us an important use of it. I don't think that there will be much application code that uses multi-dimensional opDollar, so it doesn't matter so much if those cases have a fair bit of boilerplate.

How commonly will people declare new ranges in application 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


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #5 from bearophile_hugs@eml.cc 2011-12-29 14:53:04 PST ---
At first sight I like this proposal.

(In reply to comment #4)
> How commonly will people declare new ranges in application code?

Not often enough, I think. In Python and C#4 you define new generators and iterators quite often (using the yield keyword, and in Python using lazy list comps too), but in D they are much less handy to write.

-- 
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 #6 from Andrei Alexandrescu <andrei@metalanguage.com> 2011-12-29 15:50:54 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > Let me add that it's not impossible there are ranges that do have multi-dimensional slicing but possibly no notion of "length". Sparse matrices come to mind.
> 
> Yes. Another difference is that length is generally an integer. opDollar doesn't need to be, it could be any object. It can also be cheap to calculate opDollar but expensive to determine length.
> 
> I guess the question is, for what fraction of use cases will opDollar and length coincide?

Given a value x of type T, if the user is able to write both

x.length

and

x[0 .. $]

then it should be reasonable to expect the latter is interchangeable with x[0 .. x.length].

> It seems to be true for most ranges, which is interesting because they didn't even exist when this feature was first implemented -- it was designed for matrices -- yet they're now shaping us an important use of it. I don't think that there will be much application code that uses multi-dimensional opDollar, so it doesn't matter so much if those cases have a fair bit of boilerplate.
> 
> How commonly will people declare new ranges in application code?

Hard to estimate, but I suspect a fair amount (and we want to encourage that). In STL defining an iterator is an act of courage, but we'd ideally hope that people can easily define ranges that integrate with a variety of algorithms.

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


Jonathan M Davis <jmdavisProg@gmx.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jmdavisProg@gmx.com


--- Comment #7 from Jonathan M Davis <jmdavisProg@gmx.com> 2012-10-30 22:07:29 PDT ---
It would be great to be able to rely on $ working with slicing with any range type, but right now, that would require that all sliceable ranges overload opDollar, which obviously isn't the case right now and is arguably unreasonable to expect (especially given the boilerplate involved). So, if we're going to require that $ work with slicing (which we really should do), then this proposal is pretty much 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 #8 from github-bugzilla@puremagic.com 2012-12-17 21:38:34 PST ---
Commit pushed to master at https://github.com/D-Programming-Language/phobos

https://github.com/D-Programming-Language/phobos/commit/a0b82a53b89c69102a0ab0c2e16cbb013550c723 Add some requirements for opDollar to hasSlicing.

Ideally, opDollar would be outright required for any range with slicing, but unless/until it's changed so that length automatically aliases to opDollar when opDollar isn't defined (issue# 7177), that's probably not a reasonable requirement to make.

-- 
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 #9 from Lionello Lunesu <lio+bugzilla@lunesu.com> 2013-02-06 19:53:03 PST ---
*** Issue 2635 has been marked as a duplicate of this issue. ***

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