🚀 go-pugleaf

Joe Buck wrote:
> 
> Dan Holmsand <dan@et.se> writes:
> >Is operator.() banned from the standards discussion?
> 
> Yes, I suppose it is, but since you brought it up I'll discuss it anyway.
> 
> A formal proposal to add it (from Jim Adcock of Microsoft) was voted down
> some time ago.  []
> 
> Some committee members objected that it's against the philosophy of C++ to
> change the meaning of a builtin operator.[]
> 
> Others favored a more complex and non-orthogonal version, or, worse, first
> said the proposal should be more complex and non-orthogonal and then
> objected to the complexity and non-orthogonality in this modified version.
> 
> Others objected that if both operator. and operator-> were overloaded the
> class would be just about impossible to implement, []
> 
> Others (those I respect the most) just said they didn't want extensions
> without an extremely strong reason, didn't see a strong enough reason for
> operator dot, but just wanted to get C++ standardized.  []

	For the record the _principal_ argument against 
operator.() which killed the proposal was simply that it
failed to actually provide smart references: an explicit
dot was required.

	For pointers, operator-> is OK, because
when no -> is used, you want a pointer and get
a smart pointer, and when you want an lvalue,
you have to use and explicit -> or * anyhow. 

	But for references, this is not so: 
"f(lvalue &)" requires an lvalue argument.
Operator.() (as proposed by Jim Adcock) doesn't
convert the smart reference object to a refernece
to its delegee in this context.

	As I understand it this fact was considered to
cast enough doubt on the utility of Jim's proposal
to reject it, particularly considering the potential
confusion created, and the general lack of consensus
on the issue.


-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 web: http://www.maxtal.com.au/~skaller/
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ 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://dogbert.lbl.gov/~matt/std-c++/policy.html. ]