Binding rvalues to ref parameters redux

Olivier FAURE couteaubleu at gmail.com
Fri Mar 29 11:32:28 UTC 2019


On Wednesday, 27 March 2019 at 01:38:40 UTC, Andrei Alexandrescu 
wrote:
> https://gist.github.com/andralex/e5405a5d773f07f73196c05f8339435a
>
> Thanks in advance for any feedback.

- During discussions around DIP-1016, it was pointed out that the 
following code currently compiles, even though it really 
shouldn't:

     struct Point
     {
         private int _x, _y;
         ref int x() { return _x; }
         ref int y() { return _y; }
     }

     struct Rect
     {
         private Point _origin, _size;
         Point origin() { return _origin; }
         Point size() { return _size; }
         void origin(Point p) { _origin = p; }
         void size(Point p) { _size = p; }
     }

     Rect r;
     r.origin = Point(1, 2);
     r.size = Point(5, 5);
     doubleMyValue(r.size.x);
     assert(r.lengths.x == 10); // fail

How would your proposal affect the above code? I would assume the 
code would fail to compile (at least I hope it does), in which 
case you need to include it in Breaking Changes.

Either way, the proposal should probably include a description of 
how the `this` reference of struct methods currently interacts 
with rvalues, and how it will be affected by the proposal.

- Other corner cases that were raised during discussion of 
DIP-1016: alias this, return ref, auto ref, and refs in foreach. 
The proposal needs to address those.

- return ref in particular is interesting. How do you handle the 
following code?

     int getGraphSize(ref Node);
     Node makeNode(int x);
     Node makeNode(return ref Node child1, return ref Node child2);

     // Probably should compile
     getGraphSize(makeNode(makeNode(1), makeNode(2)));

     // Probably should not
     auto persistentNode = makeNode(makeNode(1), makeNode(2));
     // Invalid write
     persitentNode.child1.x = 123;


More information about the Digitalmars-d mailing list