[fpc-devel] RFC: Support for new type "tuple" v0.1

[Mark Morgan Lloyd]

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]