Operator overloading for collections?

[Pedro Lamarão]

Em ter., 2 de set. de 2025 às 12:54, Archie Cobbs <archie.cobbs at gmail.com>
escreveu:


> Re: Semantics:
> - "no one knows what + means without looking it up" - isn't that already
> the case today?
>

This reminds of an old criticism of C++, that one does not "know without
looking up" the meaning of local variable declarations, that constructor
functions are "magic". The criticism usually went like this: in C you know
what is the effect of a local variable declaration, you know it allocates
space for a struct with Foo layout, but in C++ you don't know what is the
effect of a variable declaration, because it may run a constructor
function, which may do anything it likes -- and this not knowledge is a
problem because it is "magic".

I learned to program bare metal directly in C++ without going through C
first -- I learned and started practising both C and C++ at approximately
the same time. The above criticism never made any sense to me: the
existence of constructor functions were part of my early training and the
need to look up the effects of constructors were part of my habit while
reading foreign code. The fact that I needed to look up an initializer line
or a function call line was just the same.

I think this is a type of problem much less important then, say, the short
circuit problem -- that in C++ primitive operator&& short circuits but
overloaded operator&& does not. One could apply the same kind of
observation -- that one must lookup the meaning of code -- but to me
knowing if and in what order a machine evaluates subexpressions is a very
different kind of thing than knowing what is the definition of an operator.
I think one must know, just by looking at code, if and in what order a
machine evaluates subexpressions, without knowing what the actual
definition of each subexpression; operator && must either always short
circuit or never short circuit.

--
Pedro Lamarão
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20250902/4121f0fe/attachment.htm>