Alternate declaration syntax

[Yigal Chripun]

I wholeheartedly disagree with your post. remember, D is a compiled
language with a type system, it's not javascript.
your view of tuples adds ambiguities for both humans and compilers:
you state that tuples should be convertible to arrays and vice-versa:
int[2] = {11, "hello"} // that is a compiler error.
[int, string] = [ 1, 1]; //and so is this
tuples are implemented as anonymous _structs_ not arrays and should be
treated as such.

regarding syntax:
return 1, "hello", this;  // this should not be a tuple.

IMO, tuples must be denoted as such by either {int, string} (for
example) or if you really dislike it, than replace it with (int, string)
which is good as well. the main benefit is that I know that (a,b) is a
tuple and [a,b] is an array.
You know that often occurring bug in C/C++ where:
double res = 5 / 2; // this equals 2 and _not_ 2.5 as you (or a newbie)
would expect
well, the ambiguities of tuples versus arrays would bring the same type
of bugs if you have them both use the same syntax.

for a function to return a tuple i would suggest with the current syntax
(and parens, I've just decided I prefer them...):
pure invariant (invariant int, string) func (invariant int a, invariant
int b);
or with return values at the end, which i prefer:
// if you prefer keywords, replace colon with "returns"
pure invariant func (invariant int a, invariant int b) : (invariant int,
string);

-- Yigal

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