www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 6221] New: Should be possible to pass struct function returns by 'const ref'.

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

           Summary: Should be possible to pass struct function returns by
                    'const ref'.
           Product: D
           Version: D2
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: clugdbug yahoo.com.au



struct S6221 {
    int num;    
}

S6221 blah6221()
{
    return S6221(1);
}

void boo6221(const ref S6221 rhs) {}

void bug6221()
{
    boo6221(blah6221()); // fails; not callable with argument types S6221
}

This is a particular problem because of opCmp:

struct S
{
    int num;    
    int opCmp(const ref S rhs) const
    {
        if (num < rhs.num)
            return -1;
        else if (num > rhs.num)
            return 1;
        return 0;
    }
}

S blah() {
    return S(1);
}

void bug()
{
    bool b1 = blah() < S(45); // OK
    bool b2 = S(45) > blah(); // fails
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2011
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6221


Steven Schveighoffer <schveiguy yahoo.com> changed:

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



07:55:14 PDT ---
I think this bug is invalid.  A value-type return is an rvalue, and Andrei has
made it very clear in his posts and in TDPL that rvalues cannot be bound to
const ref parameters.  I think his reasoning is that this ability was a mistake
in C++, though I haven't gotten consistent answers as to why.

However, I cannot tell you what you are supposed to do -- I had thought that
auto ref was supposed to take care of this (i.e. you could bind an rvalue to an
auto ref parameter), but I've gotten mixed interpretations from Andrei on how
it is supposed to work.

The fact that it works with opCmp in one direction is I think a relaxation of
the rules, because struct returns would be near useless if you couldn't call
any methods on them.

I'll leave this up to Andrei or Walter to mark it invalid, in case I'm wrong.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6221






 I think this bug is invalid.  A value-type return is an rvalue, and Andrei has
 made it very clear in his posts and in TDPL that rvalues cannot be bound to
 const ref parameters.  I think his reasoning is that this ability was a mistake
 in C++, though I haven't gotten consistent answers as to why.


That's probably true. But that has consequences. We can't discard that C++
behaviour and yet keep the C++ behaviour of using const ref in operator
overloads:


 The fact that it works with opCmp in one direction is I think a relaxation of
 the rules, because struct returns would be near useless if you couldn't call
 any methods on them.


This is a serious problem. opCmp behaviour MUST be symmetrical.

S foo() {...}
S x;

  x > foo()
  foo() < x
  foo() > foo()

If any of these compile, they must all compile.

As far as I can tell, a 'const ref' parameter on pretty much any operator
overload, is a bug. In fact it's difficult to come up with _any_ scenarios
where 'const ref' makes sense.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 29 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6221




07:24:09 PDT ---
Like I said, I don't know what the right solution is.  Previously I thought
auto ref was the solution, but I'm not so sure.

I agree operators need to accept rvalues, but I don't think const ref will be
acceptable to Andrei.  If this bug report was changed to "it should be possible
to pass both rvalues and lvalues to operators," it would be a valid bug.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6221




Shouldn't opCmp be relaxed like opEquals in bug 3659?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jun 30 2011
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6221






 Shouldn't opCmp be relaxed like opEquals in bug 3659?


It is indeed the same issue. But I'm not convinced by the proposed solution in
bug 3659. We don't need more options -- we just need one GOOD one.

IMHO, this is *the* remaining black hole in the language. We have a zoo of
parameter passing options -- in, inout, out, ref, const ref, auto ref
-- and yet it's not possible to express the most basic parameter passing
option: "I want read-only access from this value, and I give the compiler
freedom to pass it as efficiently as possible."

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jul 01 2011
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=6221


Jonathan M Davis <jmdavisProg gmx.com> changed:

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



PST ---
I think that const auto ref does the trick, assuming that that works with
opCmp, but for some reason, it only works with templated functions at the
moment. I thought that it was supposed to work with non-templated functions as
well. If it doesn't, then I guess that the forced solution is to define an
overload which takes a const ref and one which takes the argument by value. It
would be much simpler if const ref could take a temporary, but Andrei is dead
set against that solution.


A related issue is the fact that

boo6221(S6221(5));

compiles while

boo6221(blah6221());

does not, since (for reasons that I've never understood) a struct literal is


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