🚀 go-pugleaf

In article <Bs6n59.GD@world.std.com> wmm@world.std.com (William M Miller) writes:
>The reason I "ignore" this point is because it is irrelevant to the subject
>of the analysis I was making -- that built-in "." is different from built-in
>"->" because the former does not have a corresponding run-time operation,
>while the latter does.  Since the built-in "." has no runtime operation, it
>does not make sense, IMHO, to allow an overloaded operator.(), since
>overloaded operators are primarily runtime operations (calling a function to
>perform some action).  The built-in "->" _does_ perform a runtime operation
>(indirection), so providing an overloaded operator->() does make sense from
>this perspective.

I don't want to take any sides in this mudfight, but the preceding
analysis strikes me as particularly bogus.  Without looking at the
assembly language, you don't know what "." or "->" do in terms of
run-time operations.  In different contexts (in C, ignoring C++) they
do different things -- for instance, "&(X -> a)" is not performing an
indirection.  In certain compilation modes (e.g., position independent
code generation) they do different things at run-time.  If you're
interpreting the program, they may do other different things at
run-time.  From my current point of view (head firmly stuffed into the
back-end of a compiler) it all looks like bits, and (after cfront and
cc and the optimizer get through with them) not very attractive bits.

So, do please try not to confuse the language specification with the
language implementation/compilation.  (Didn't I say this once already
in a different context?)  If, generally speaking, a proposal isn't a
run-time turkey (a well-defined term, eh?), then it ought to be
evaluated on how well it works with the rest of the language and what
programmers need.

David Chase
Sun