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

[Alexander Klenin]

On Mon, Jan 28, 2013 at 2:01 AM, Martin <lazarus at mfriebe.de> wrote:
>> Of course. But note that in this thread, many more uses of tuples
>> (which I do NOT want to make a type -- see my previous mail for
>> lengthy explanation why).
>> Some of the uses are: record and array constructors, adaptation of
>> inconvenient signatures,
>> better support for "return code" style of error handling, etc.
>
> If I understand this correct, the ability to return more than one value from
> a function (without out parm) is identical to using a record.
> Except you do not want a type declaration for a record.

Actually, I have nothing against type declaration of record.
What I want to relax is the restriction that the *caller* must use
a record to receive the value too -- I want to allow assigning result
directly to a list of variables.

> Therefore in this case tuple becomes an "inline" (lack of better word)
> declared record (match like you can declare an array outside a "type"
> section)
Yes, this is exactly why I am against introducing tuples as a new data type --
"inline" (I prefer term "anonymous") records are good enough.

> And since it has no named type, it is (other tan records) assignment
> compatible if it has the same declaration (same as 2 "array of integer",
> only array can not hold different types)
> So really here you would need an assignment compatible record (I do not say
> it is a good thing, but if the multi return case is addressed, it may be a
> better way than toupe)
>
> type
>   TFoo1 = compatible record  a: integer; b: string end;
>   TFoo2 = compatible record  a: integer; b: string end;
>
> function Bar: compatible record  a: integer; b: string end;
>
> and variables/results of any of these are assignment compatible.
> ("compatible record" can be restricted to none variant records)
I do not think "compatible" records are good enough, because with named records,
the same effect can be achieved simply by type conversion:
x := TFoo1(Bar);

What I want is:
var
  a: Integer;
  b: String;
  c: TIntegerDynArray;
  x: TFoo1;

a, b := Bar;
c[0], b := Bar;
c[i], c[j] := c[j], c[i];
x := Bar; // This will not work with anonymous record
x := TFoo1(a, b);
a, b := x;

etc.

Note that, except for the commented line, it does not matter whether
Bar is declared as
function Bar: TFoo1;
or
function Bar: record  a: integer; b: string end;

>> I have a compromise suggestion:
>> Implement for-index extension with the syntax:
>> for (k, v) in a do
>
> can be solved with records too?
>
> The typeof(a) needs to declare the key values anyway (provide an iterator,
> or something)
>
> So together with that, a named record (normal record as exists today) can be
> defined? Or am I missing something?

You got it right.
More detailed, I suggest to extend Enumerable interface with optional
property CurrentWithKey: TValueKey
where TValueKey must be a record of two (or perhaps even more) fields.
for k, v in a do
will call CurrentWithKey for each item, assign first field to k, second -- to v.
When/if tuples will be introduced, no change will be needed here.

--
Alexander S. Klenin