🚀 go-pugleaf

Article 15876 of comp.std.c++:
>From: jason@cygnus.com (Jason Merrill)

 > >>>>> Joe Buck <jbuck@Synopsys.COM> writes:
 > 
 > > Stroustrup proposes that operator. only forward to the resulting class
 > > for a.m if the object itself doesn't have a member m.  I dislike that
 > > approach; it is unnecessary since (&a)->m accesses it, and since
 > > the class is going to present itself as a disguised reference object
 > > in any case, only private code is going to mess around with the object's
 > > own members.  In member functions, one would merely write "m".

I don't propose anything. I discuss a couple of alternatives in
D&E sec11.5.2 (including the one Joe Buck states a preference for).
I happen to weakly prefer the resolution Joe Buck refers to as mine,
but my conclusion stands:

	``The C++ community seems split over the issue of which
	interpretation of operator.() is best.''

	...

	``there is no consensus on the importance of operator.()
	either. Consequently, operator.() isn'r part of C++ and
	the debate rage on.''

We did not have and we do not have the consensus necessary for
inclusion in the standard and I do not know how to build one.
The committee seriously considered operator.() on several occations
over a couple of years. By now, the discussion is academic.

 > I think a more natural way to achieve the delegation semantics proposed by
 > Stroustrup would be to extend 'using' along these lines:
 > 
 > struct A {
 >   void f  ();
 > };
 > 
 > struct ARef {
 >   A* a;
 >   using *a;
 > };
 > 
 > main ()
 > {
 >   ARef ar = { new A };
 >   ar.f (); // (*(ar.a)).f();
 > }
 > 
 > Of course, that's not likely to happen either.

Exactly. However, I did think of that years ago, and tried it out
(with a different syntax). The results of the experiment were strongly
negative. See D&E sec 12.7.

	- Bjarne
 > Jason

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
]