www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2984] New: Failure to find front/back/popBack/popFront/etc should fall back to opApply

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984

           Summary: Failure to find front/back/popBack/popFront/etc should
                    fall back to opApply
           Product: D
           Version: unspecified
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: 2korden gmail.com


I have a Vector class which is modeled after std::vector. As such, it has
front, back, popBack but no popFront method. DMD2.029 fails to compile foreach
over the vector because it lacks popFront even though there are opApply
overloads for it. Marking it as a regression since it used to compile with
DMD2.028 although it used other primitive names. Here is a cut-down code to
reproduce the problem:

module Vector;

public struct Vector(Type)
{
    private uint    _size = 0;
    private Type[]  _elements = null;

    uint length()
    {
        return _size;
    }

    bool empty()
    {
        return _size == 0;
    }

    void popBack()
    in
    {
        assert(_size >= 1);
    }
    body
    {
        --_size;
    }

    Type back()
    in
    {
        assert(!empty());
    }
    body
    {
        return _elements[_size-1];
    }

    Type front()
    in
    {
        assert(!empty());
    }
    body
    {
        return _elements[0];
    }

    int opApply(int delegate(ref Type value) dg)
    {
        for(uint i=0; i<_size; ++i)
        {
            int result = dg(_elements[i]);
            if( result != 0 ) {
                return result;
            }
        }

        return 0;
    }

    int opApply(int delegate(ref uint index, ref Type value) dg)
    {
        for(uint i=0; i<_size; ++i)
        {
            int result = dg(i, _elements[i]);
            if( result != 0 ) {
                return result;
            }
        }

        return 0;
    }
}

void main()
{
    Vector!(int) v;
    foreach (int i; v) {
        // do nothing
    }
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 15 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984





--- Comment #1 from Koroskin Denis <2korden gmail.com>  2009-05-15 16:21:50 PDT
---
Error message issued:
Vector.d(83): Error: no property 'popFront' for type 'Vector!(int)'

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984





--- Comment #2 from Koroskin Denis <2korden gmail.com>  2009-05-15 16:22:13 PDT
---
Note that adding

Type[] opSlice()
{
    return _elements[0.._size];
}

to the Vector struct will result int the following error message instead:

Error: undefined identifier module Vector.empty
Error: function expected before (), not module Vector.empty of type void
Error: undefined identifier module Vector.popFront
Error: function expected before (), not module Vector.popFront of type void
Error: undefined identifier module Vector.front
Error: function expected before (), not module Vector.front of type void

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 15 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug yahoo.com.au
           Severity|regression                  |major


--- Comment #3 from Don <clugdbug yahoo.com.au> 2009-11-16 07:34:06 PST ---
This isn't a regression -- the language changed. Bug 3514 expresses this
better.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984



--- Comment #4 from Koroskin Denis <2korden gmail.com> 2009-11-16 07:47:14 PST
---
Well, yes. It is a regression in a sense that the code used to compile but it
doesn't anymore. It sees a front(), back() and empty() methods in my Vector
struct (which is designed after std::vector and thus has similar members) and
mistakenly assumes it is a range (and it's not).

The language change shouldn't have caused this compilation error, be it
implemented more correct, that's why I marked it as a regression :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Nov 16 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984


Leandro Lucarella <llucax gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsimcha yahoo.com


--- Comment #5 from Leandro Lucarella <llucax gmail.com> 2009-11-16 12:44:28
PST ---
*** Issue 3514 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: -------
Nov 16 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2984


Steven Schveighoffer <schveiguy yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE


--- Comment #6 from Steven Schveighoffer <schveiguy yahoo.com> 2009-11-16
14:04:03 PST ---
Although bug 3514 came later, it captures more information, and following the
fix prescribed in 3514 would make this bug sort of moot.  There is no reason to
have a special case of partially implemented range functions vs. opApply --
opApply should be the default choice even with valid range functions.

*** This issue has been marked as a duplicate of issue 3514 ***

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