Alexander Klenin wrote:
2) The most important differentiating features of my proposal are:
2.1) Tuples are always temporary and anonymous. You can not store a
tuple, define tuple type, of variable of tuple type.
So tuples are 100% static, compile-time feature -- no change to
RTTI, variants etc.
If you can't define a tuple type then you can't check that it's
assignment-compatible with e.g. an array.
2.2) Tuples construction: after some thinking, I propose to define a
plain comma as an operator creating a tuple.
I must say that I prefer the idea of any collection being in some form
of brackets. I'm tempted to say "any language extension being in
bracket-like entities", even if that's paired keywords.
This way, any comma-separated list is considered a tuple, and
parenthesis may be used simply to control priority,
since priority of comma is lower than all other operators. I will
demonstrate below how the compatibility with existing features is
still preserved.
2.2.1) Tuples are *flattening*, so (1, 2, (3, 4)) is a tuple of 4
elements, not of 3 elements, last being tuple.
I've got a bad feeling about that. Apart from anything else I think it
implies that (pseudocode)
(TPoint, TColor) := (TColor, TPoint);
would be valid.
Single-value tuples are
useless, so Tuple(1) is either a no-op or error.
Except that a variant of that could be used to expand an element to a
tuple. Or provided that tuples *did* *not* flatten it could expand a
tuple to a tuple-of-tuples.
type TPoint= tuple of Double;
TRect= tuple of TPoint;
var rect: TRect;
begin
rect := TRect(TPoint(100.0));
OK, so that's a zero-size rectangle but I'm trying to demonstrate
potential syntax rather than do anything useful.
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
