Alternate declaration syntax

[Hans W. Uhlig]

Koroskin Denis wrote:
> On Sun, 13 Apr 2008 12:07:11 +0400, Georg Wrede <georg at nospam.org> wrote:
>> Hans W. Uhlig wrote:
>>>  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;
>>> }
>>
>> Well, at first sight, this looks nice.
> 
> Doesn't look nice to me. Look at this:
> 
> auto t = 1, "hello", this;
> 
> What it the t.typeof? Do you think it's {int, string, this.typeof}?
> No, it's just this.typeof, because comma is a statement separator in 
> this context.
> Moreover, I don't think this is consistent:
> 
> int i;
> string s;
> this.typeof t;
> 
> {i, s, t} = 1, "hello", this;
> 
> Compare to:
> {i, s, t} = {1, "hello, "this};
> 
> or to:
> [i, s, t] = [1, "hello", this];
> 
> Anyway, I don't like {} syntax much. I believe, in D it denotes scopes.
> Even array initialization moved from C style {1, 2, 3} to D style [1, 2, 
> 3].
> 
> To me, tuples aren't different from arrays. And I would like to operate 
> on them like on arrays:
> 
> auto t = [1, "hello", this];
> auto s = t[0..1]; // s == {1, "hello" }. t{0..1} looks like an ugly 
> language hack to me.
> 
> Or like this:
> 
> {int, int, string} k = [1, 2, "3"];
> k[0..1] = [1, 1];   // here it is. What is the type of [1, 1]? I don't 
> care!
> int[2] i = k[0..1]; // Arrays should be convertible to tuples and 
> vice-versa
[] would fit the paradime anyhow. Perl actually uses (x,y,z) = (a,b,c); 
so using [a,b,c] I thin k would work fine. As for initialization inside 
a "touple bracket" I think it should be eigther allowed only with auto 
(at which point the compiler should effectively treat each variable as a 
seperate statement, i.E.

(auto i, j, k) = blah();
auto i = blah()[0];
j = blah()[1];
k = blah()[2];


since as I understand it, a touple is effectively an anonymous array

return a,b,c; becomes

void * touplereturn[] = [&a, &b, &c];
return touplereturn;

at which point you simply retreive the resulting array and process

perhaps this is where some native(rather then library) array 
handling/dereferencing might be appropriate.

when using standard vs touple syntax, if Walter wants to avoid the 
suggested syntax as being too pascal like

touple foobar(int a, int b, int c) returns int, double, string {}

such that touple is an array reference containing references, and the 
compiler then looks to the property returns for the return types. 
However, at least in my mind this is a horrendous cluge but still 
providdes the neccessary type checking and compiler enforcement.

while I think this is a hack and leads to more confusion it would 
provide a bit more readability then otherwise would be gained.

so, in short, my vote for the declaration statement moves to the end of 
the line

function <identifier>(<<parameter modifier, ...> parameter, ...>) 
returns <<return modifier> return type, ...> { // block

	returns [x,y,z]; or returns x,y,z;
	returns [x]; or returns x;
}

[x,y,z] = foo();
[auto x, auto y, z] = foo();

comments?