Sven Barth schrieb:
The lack of element names results in bloated code and runtime overhead.
See below.
I don't see why it should result in bloated code and runtime overhead.
---> See below ;-)
(a, b) := (b, a); // the compiler needs to ensure the correct usage
of temps here!
What will happen here?
At compile time a tuple type (integer; integer) has to be defined, and
an instance must be allocated for it. Initialization and finalization
information/code must be added if required.
At runtime the arguments are copied into that tuple instance, then
copied into the target variables. All "copies" may be subject to type
conversions and reference counting.
And here you are wrong. We have an assignment node with a tuple node on
the left and a tuple node on the right. So the compiler can insert
direct assignments between the corresponding elements on the left and
right maybe with the need to insert a few temp vars to resolve cases
like the above.
Are you sure that the compiler will detect all (possible) side effects,
so that an optimization is always *safe*?
Finally somebody (you?) has to implement all the new features, and stand
for its correctness.
a := 42;
(a, e) := (a * 2, a); // (a, e) should be (84, 42), not (84, 84)
Such code tends to become cryptic with larger tuples.
High level (source code) debugging will be impossible :-(
You can also write cryptic code without tuples. Also why should
debugging become impossible? It's "just" a matter of adding the correct
debug information.
With explicit assignments you can check every single statement,
eventually step into embedded functions. A tuple assignment is a single
statement, no chance to find out what happens in detail.
DoDi
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
