I saw someone talking about this kind of thing

int var1, var2;
(var1, var2) = test(3);

being added to the language... Now, the use of the out keyword obviously makes this undeeded, but the out keyword is very hard to understand by looking at the code when using the function.

test(var1, var2);

Cause you have to know a little more about the function to know it will only be returning value to those variables..

What if it was like this...

([returns]) [name]([arguments]...)
{
	[body]
}

example

(int _out1, int _out2) test(int _input)
{
	_out1 = _input + 1;
	_out2 = _input + 2;
	return(_out1, _out2);
}

and for a normal, single output function it would be as usual. The definition of the return value needs to name, cause it's the only one, and thus using the () after return is not needed.

this way

(always out) test(in or inout)
{
	return value or (list of values)
}

I think since the out keyword is used so little, it would break VERY little code, and would really make allot more sense when using the code..


int var1, var2;
(var1, var2) = test(3);

is more self descriptive than

int var1, var2;
test(3, var1, var2);

my 2 cents...
-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

Trevor Parscal wrote:
> I saw someone talking about this kind of thing
> 
> int var1, var2;
> (var1, var2) = test(3);
> 
> being added to the language... Now, the use of the out keyword obviously makes this undeeded, but the out keyword is very hard to understand by looking at the code when using the function.
> 
> test(var1, var2);
> 
> Cause you have to know a little more about the function to know it will only be returning value to those variables..
> 
> What if it was like this...
> 
> ([returns]) [name]([arguments]...)
> {
>     [body]
> }
> 
> example
> 
> (int _out1, int _out2) test(int _input)
> {
>     _out1 = _input + 1;
>     _out2 = _input + 2;
>     return(_out1, _out2);
> }
> 
> and for a normal, single output function it would be as usual. The definition of the return value needs to name, cause it's the only one, and thus using the () after return is not needed.
> 
> this way
> 
> (always out) test(in or inout)
> {
>     return value or (list of values)
> }
> 
> I think since the out keyword is used so little, it would break VERY little code, and would really make allot more sense when using the code..
> 
> 
> int var1, var2;
> (var1, var2) = test(3);
> 
> is more self descriptive than
> 
> int var1, var2;
> test(3, var1, var2);
> 
> my 2 cents...


I would suggest a simpler syntax:

  parameter-list :: in-parameter-list? (semi-colon out-parameter-list)?

For example:

int test1(int in1, int in2 ; int out1, int out2);
int test2(int in1, int in2);
int test3(; int out1, int out2);

However, I don't think it's worth the effort to change the status quo only for a more Lisp-like look.

Trevor Parscal <trevorparscal@hotmail.com> wrote:

[...]
> would really make allot more sense when
> using the code..
>   int var1, var2;
>   (var1, var2) = test(3);
> is more self descriptive than
>   int var1, var2;
>   test(3, var1, var2);

You are loosing sense, because overloading is based on the list of arguments.

-manfred

Manfred Nowak wrote:
> Trevor Parscal <trevorparscal@hotmail.com> wrote:
> 
> [...]
> 
>>would really make allot more sense when
>>using the code.. 
>>  int var1, var2;
>>  (var1, var2) = test(3);
>>is more self descriptive than
>>  int var1, var2;
>>  test(3, var1, var2);
> 
> 
> You are loosing sense, because overloading is based on the list of arguments.
> 
> -manfred

Why couldn't overloading be also based on the types and number of returns requested..?

-- 
Thanks,
Trevor Parscal
www.trevorparscal.com
trevorparscal@hotmail.com

Trevor Parscal <trevorparscal@hotmail.com> wrote:

[...]
> Why couldn't overloading be also based on the types and number of returns requested..?

Because such extension would at least impose further rules for the resolution of ambiguous calls and may even lure the compiler on to destruction, because the resulting problems may be undecidable.

Simple example:

int f (){...};
( int, int) f(){...};
void g( int, int, int){...};

g( f(), f());

-manfred

"Trevor Parscal" <trevorparscal@hotmail.com> wrote in message news:d93nfo$25m0$1@digitaldaemon.com...
> being added to the language... Now, the use of the out keyword obviously makes this undeeded, but the out keyword is very hard to understand by looking at the code when using the function.
>
> test(var1, var2);

In C#, this is solved by requiring the use of "ref" (equivalent of inout) and "out" when _calling_ the function as well:

test(out var1, out var2);
test2(inout var3);

I'd love to see this in D, as it serves to make it more obvious that these variables are returns or are being modified.

In article <d943m2$2ck7$1@digitaldaemon.com>, Manfred Nowak says...
>
>Trevor Parscal <trevorparscal@hotmail.com> wrote:
>
>[...]
>> Why couldn't overloading be also based on the types and number of returns requested..?
>
>Because such extension would at least impose further rules for the resolution of ambiguous calls and may even lure the compiler on to destruction, because the resulting problems may be undecidable.
>
>Simple example:
>
>int f (){...};
>( int, int) f(){...};
>void g( int, int, int){...};
>
>g( f(), f());
>
>-manfred

This is not what was proposed originally by myself.  Passing LISP-like tuples as replacements for sets of parameters in a function call would not be allowed. However, I can't speak for Trevor's proposal, so that's really up to him.

My version of the out-parameter list is strictly for assignment operations only.

Regards,
James Dunne