Alternate declaration syntax

[Scott S. McCoy]

On Sun, 2008-04-13 at 10:40 -0700, Hans W. Uhlig wrote:
> 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


You realize this is functionally defunct for the purposes of type
inference?  Just thought I'd run that by you.  What we would need, for
list context, is the same type of return type-checking we currently
have, but with multiple values.

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