Alternate declaration syntax

[Hans W. Uhlig]

Hans W. Uhlig wrote:
> Yigal Chripun wrote:
>> Koroskin Denis wrote:
>>> Talking about multiple return values, I'd like to see the following
>>> syntax:
>>>
>>> // both types are 'int's (just for simplicity)
>>> [int, int] someFunction()
>>> {
>>>     return [1, 2];
>>> }
>>>
>>> instead of, for example,
>>>
>>> Tuple!(int,int) somFunction()
>>> {
>>>     return Tuple!(int,int) {1, 2};
>>> }
>>>
>>> In fact, Tuple!(int,int) isn't that different from int[2].
>>> They share 'length' property, and I like result[0] more than result._0,
>>> 'cause it's simpler, more intuitive and behaves just like built-in type:
>>>
>>> auto result = someFunction();
>>>
>>> auto len = result.length; // compile-time evalualable
>>> auto r0 = result[0];      // types can be easily deduced
>>> auto r1 = result[1];
>>> auto r2 = result[2];      // fails to compile, out of bounds.
>>>
>>> Whaddya think? :)
>> I like the basic idea, although I would prefer a different operator 
>> than [].
>> basically, my only issue is that when i see res[i] I would assume that
>> res is an array.
>>
>> Tuples have much more in common with structs than with arrays, and as
>> such, I would prefer:
>>
>> {int, double} someFunction()
>> {
>>     return {1, 2.5};
>> }
>>
>> and:
>>
>> auto result = someFunction();
>>
>> auto len = result.length; // compile-time evalualable
>> auto r0 = result{0};      // types can be easily deduced
>> auto r1 = result{0,1};  // define a new tuple with a subset of result's
>> values
>>
>> or:
>>
>> result.at(0);
>>
>> or even something similar to ML's:
>> r1 = $1(result) ; // second item in tuple
>>
>> -- Yigal
>>
> In this I must agree, using
> 
>     return {1,"string",objectref}; is far cleaner then eigther prior 
> reference.
I would think something similar to perl would work

{var1, var2, var3} = blah(1,2,3);
{int var1, string var2, object var3} = blah(1,2,3);

const blah(int a, int b, int c) returns const int, invariant string, 
object {
	return 1, "hello", this;
}