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

[Martin]

On 27/01/2013 14:42, Alexander Klenin wrote:
> On Mon, Jan 28, 2013 at 1:26 AM, Paul Ishenin <paul.ishenin at gmail.com> wrote:
>> 27.01.13, 1:43, Sven Barth wrote:
>>> Based on the results of the "for-in-index" thread I've decided to come
>>> up with a draft for the Tuple type which is thought by many people to be
>>> a better alternative to "for-in-index".
>> I think it is big overkill to implement a new base type for such a small
>> task as returning a key in for-in loop.
> 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.

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)
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)


>> And (for Michael) I don't see any beauty in this. Imo, initial index
>> extension is much more beauty than suggested here (a,b,c) := d;
>> constructions.
> 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?