[fpc-devel] for-in-index loop

[Alexander Klenin]

On Sat, Jan 26, 2013 at 10:58 PM, Sven Barth
<pascaldragon at googlemail.com> wrote:
>
> I mean less the implementation specific details, but more the syntax they
> chose:
>
> === example begin ===
>
> TTestTuple = tuple of (Integer, String, TObject);
>
> var
>   t: TTestTuple;
>   i: Integer;
>   s: String;
>   o: TObject;
> begin
>   t := (42, 'Hello World', TObject.Create); // ok, this can be considered
> nightmarish syntax again... (see below)
>   (i, s, o) := t;
>   // and yes this could also provide the possibility for multiassignments
>   (i, s, o) := (42, 'Hello World', TObject.Create);
> end;
>
> === example end ===
>
> The only thing I have a problem with is to use "(...)" as the syntax element
> for tuples... e.g. is "(42)" an integer or a "tuple of (Integer)"? We'd need
> to either enforce that "tuple of (...)" needs an element count > 1 or that
> "tuple of (SomeType)" is assignment compatible to just "SomeType" (we'd need
> something like this, because of backwards compatibility).
>

Note that my proposal specifically forbids to create "named tuples",
because named tuples are just records :)
As for syntax ambiguity -- I agree it is a problem. Perhaps a symbol
to denote tuple could be chosen
(e.g. @@), and is required in front of *all* tuples:
@@(a, b) = @@(b, c);
@@(first, second) = @@FunctionReturningArray;
ProcWithmanyParams(@@p);
... etc
unfortunately, this will also require
for @@(v, i) in a do
which is not nice.

Another possibility is to resolve single element in brackets in favor
of a simple value, and require explicit call to Tuple
to disambiguate -- single-element tuples are useless anyway, so will be rare.

--
Alexander S. Klenin