May 20, 2005
In article <d6k4uo$f3h$1@digitaldaemon.com>, TechnoZeus says...
>
>"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d6k1qi$bbj$1@digitaldaemon.com...
>> I wish return values were thought of as an additional (hidden) "inout" argument to the function. Much like "this" is a hidden "in" argument when calling methods of an object.
>>
>> If this could be consistently done, then it would not only allow for "return-type function overloading" but maybe also create the possibility of returning multiple values (tuples)! (which basically comes down to inventing a nice-enough syntax for it)
>>
>> L.
>>
>>
>
>Beautiful idea... I really like this one.  :)
>

Yup. My thoughts exactly.

I have always thought the inout parameter concept was flawed. A function should take in values at one end, and spit them out at the other. Anything else leads to uncertainties about what's really going on. This has been demonstrated enough in the "require inout on function calls" thread. Egads! What is the need to perpetuate this blatantly obvoius inconsistency?! *slams keyboard*

> <snip>
>void main()
>{
>  int,real x() { return 9,1.2;}
>  printf("___%d___%g___",x);
>  real b = x.real;
>}
> <snip>
>
>TZ
>

This one has my vote. Simple and intuitive. Bliss.

May I suggest an addition though? Since function names can be quite long, one may not want to *have* to use it in order to access the return parameters.

Thus:
:void main()
:{
:  int a; real b;
:  int, real longFunctionNameBonanza() { return 9, 1.2;}
:  [a, b] = longFunctionNameBonanza();
:  printf("___%d___%g___", a, b);
:}

This practise is common in Perl, of all languages, and it's quite pleasant to get used to.

-Nod-


May 21, 2005
"Nod" <Nod_member@pathlink.com> wrote in message news:d6loem$1p7r$1@digitaldaemon.com...
> In article <d6k4uo$f3h$1@digitaldaemon.com>, TechnoZeus says...
> >
> >"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d6k1qi$bbj$1@digitaldaemon.com...
> >> I wish return values were thought of as an additional (hidden) "inout" argument to the function. Much like "this" is a hidden "in" argument when calling methods of an object.
> >>
> >> If this could be consistently done, then it would not only allow for "return-type function overloading" but maybe also create the possibility of returning multiple values (tuples)! (which basically comes down to inventing a nice-enough syntax for it)
> >>
> >> L.
> >>
> >>
> >
> >Beautiful idea... I really like this one.  :)
> >
>
> Yup. My thoughts exactly.
>
> I have always thought the inout parameter concept was flawed. A function should take in values at one end, and spit them out at the other. Anything else leads to uncertainties about what's really going on. This has been demonstrated enough in the "require inout on function calls" thread. Egads! What is the need to perpetuate this blatantly obvoius inconsistency?! *slams keyboard*
>
> > <snip>
> >void main()
> >{
> >  int,real x() { return 9,1.2;}
> >  printf("___%d___%g___",x);
> >  real b = x.real;
> >}
> > <snip>
> >
> >TZ
> >
>
> This one has my vote. Simple and intuitive. Bliss.
>
> May I suggest an addition though? Since function names can be quite long, one may not want to *have* to use it in order to access the return parameters.
>
> Thus:
> :void main()
> :{
> :  int a; real b;
> :  int, real longFunctionNameBonanza() { return 9, 1.2;}
> :  [a, b] = longFunctionNameBonanza();
> :  printf("___%d___%g___", a, b);
> :}
>
> This practise is common in Perl, of all languages, and it's quite pleasant to get used to.
>
> -Nod-
>
>

Yes, I've seen set assignments like that in other languages also.  Works nicely.
Basically, [a,b] would be an anonomous set in that context,
with it's elements being independant of each other outside of the context of that set.

For those who are unfamilliar with such notation, the order of the elements is matched in the assignment.

In other words...
[a,b,c] = [d,e,f];
is the same as...
a = d; b = e; c = f;

This can be generalized further to include operations such as...
[a, b] = [c, d] + [e, f];
meaning roughly the same thing as...
a = c + e; b = d + f;
except that the order of operations would be to do the additions first and then do the assignments...
as if the set of additions were a "group addition" operation.
This goes along with the fact that...
[a,b]=longFunctionNameBonanza();
first evaluates longFunctionNameBonanza() and then assigns the return values to [a,b] in the order that they appear on the return statement.
Again, there is the question of syntax.  Should it be....
[a,b] = [c,d];
or would it be better to use...
a,b = c,d;
and there is also the issue of what the following means, if anything...
int a;
int b;
int c=9;
[a,b] = c;
where it could be defined as an error, or as assigning the value of c to both a and b
as if it were assigning an array element type value to an array.

TZ


May 21, 2005
"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:d6kvhl$15fr$1@digitaldaemon.com...
> Lionello Lunesu wrote:
> > I wish return values were thought of as an additional (hidden) "inout" argument to the function. Much like "this" is a hidden "in" argument when calling methods of an object.
> >
> > If this could be consistently done, then it would not only allow for "return-type function overloading" but maybe also create the possibility of returning multiple values (tuples)! (which basically comes down to inventing a nice-enough syntax for it)
> >
> > L.
> >
> >
>
> You can use a Box or an array of Boxes as the return type.
> This way, you can return anything you want, and if you use an array, you
> can return many thngs of any type you want.

Right, but those thing have to first be put into an array, as things are now.

Consider, for example, the following hypothetical code, using multiple return values...

prevnext(int x;){return x-1, x+1;}

void main(){
int a; int b; int c;
int d = 1;
int e; int f; int g;
b,f = prevnext(d);
a,c = prevnext(b);
e,g = prevnext(f);
if (c == e) [e,c] = prevnext(d);

Notice that in the last assignment, I reversed the order of the elements?
This type of notation removes a lot of the restrictions associated with using an array as a function's type,
and allows otherwise entirely unconnected items to be used as a set without any
 declaration of a names type or item to contain the temporary set that they compose.

TZ


May 22, 2005
TechnoZeus wrote:
> Beautiful idea... I really like this one.  :)
> 
> But yes, coming up with a good syntax could be an issue.
> 
> My first thought was, perhaps something similar to a built in struct with optional members...
> 
> void main()
> {
>   struct{int,real} a() { return {9,1.2}}
>   printf("___%d___%g___",a);
>   real b = a.real;
> }
> 
> but then I thought... what else could "int,real x" mean?
> 
> void main()
> {
>   int,real x() { return 9,1.2;}
>   printf("___%d___%g___",x);
>   real b = x.real;
> }
> 

How about:

void main()
{
  real,real x() { return 9.0,1.2;}
  printf("___%d___%g___",x);
  real b = x.real;             //ambiguity: which one??
}
May 22, 2005
On Fri, 20 May 2005 02:15:10 -0500, TechnoZeus <TechnoZeus@PeoplePC.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opsq1tkott23k2f5@nrage.netwin.co.nz...
>> Try this one:
>>
>> void foo(long a) {}
>> void foo(float a) {}
>>
>> void main()
>> {
>> foo(5);
>> }
>>
>> The error reads:
>>
>> pick.d(6): function pick.foo called with argument types:
>> (int)
>> matches both:
>> pick.foo(long)
>> and:
>> pick.foo(float)
>>
>> This is because 'int' is implicitly castable to both 'long' and 'float'.
>>
>> Regan
>
> Now, I would have espected it to choose long over float
> since long anf int are both integer types and float is not...

Yeah, that's about the only possible criteria for selecting one over the other. After all you can safely convert to either with no loss of data. I prefer the error to selecting either, it seems to me that there is too large a possibility for a typo (forgetting the .0 on 5.0), or no knowledge of one of the overloads to mean an error.

> however, I would say that if this ambiguity of passed parameters
> would cause a compile-time error, then the same ambiguity when applied to
> a choice of overloaded functions based on return types should also cause
> a compile-time error... for consistancy.

Agreed. Where ppl seem to disagree is what the soln for that would be :)

Regan
May 23, 2005
> You can use a Box or an array of Boxes as the return type.
> This way, you can return anything you want, and if you use an array, you
> can return many thngs of any type you want.

Yes, but boxing adds some overhead though. If I but two reals in a box (both in a box array) and then the boxes are checked for the right type when trying to get the reals of them.

Basically, I'm suggesting something like an anonymous struct, and some easy syntax to create it 'on the fly', without the need to declare a struct for each combination of return values.

Instead of writing:

struct point_t {
 int a;
 int b;
};
point_t getPoint();

..it would be nice if you could write:

struct {int a;int b;} getPoint();

Maybe this syntax can be simplified even more, using an implicit struct:

int, int getPoint();

Might result in some parsing problems though. In any case, it should be possible to retreive the values in seperate variables (who are not themselves in a similar struct):

int b;
// do something with b
int a;
a,b = getPoint();

Note that I don't like calling a function add being able to retreive only
one of the return values, as mentioned in an earlier example: a =
getPoint().int;
First of all there's the ambiguity, but also the fact that this simply
shouldn't be encouraged. You should retreive all of the values, or none, to
prevent people calling getPoint().real and .int (with whatever syntax that
would solve the ambiguity), since the function will be evaluated twice.
Possibly resulting in a nonsense pair of values, but in any case resulting
in the code being executed twice!

L.

L.


May 23, 2005
> How about:
>
> void main()
> {
>   real,real x() { return 9.0,1.2;}
>   printf("___%d___%g___",x);
>   real b = x.real;             //ambiguity: which one??
> }

Good example. You shouldn't be able to do that in the first place. All the values must be retreived, or none.

Allowing that kind of code (retreiving only one of the return values) results in the function being called twice, possible returning a different pair of values. From the original example: int a = x.int; real b = x.real; The pair a,b might be totally useless, since the function x was evaluated twice.

L.


May 23, 2005
i Like:

(int,double) func (int param) {
	......
	......
	return (a,b);
}


int a;
double b;

(a,b) = func(0);



This is possible to implement, I'm sure.

Unfortunately, I doubt Walter would consider it. He doesn't seem interested by such dramatically "new" ideas.

I regret that. There should be an "unofficial" DMD version reserved for implementing crazy things like that and test.







Le Mon, 23 May 2005 10:58:19 +0300, Lionello Lunesu a écrit :

>> You can use a Box or an array of Boxes as the return type.
>> This way, you can return anything you want, and if you use an array, you
>> can return many thngs of any type you want.
> 
> Yes, but boxing adds some overhead though. If I but two reals in a box (both in a box array) and then the boxes are checked for the right type when trying to get the reals of them.
> 
> Basically, I'm suggesting something like an anonymous struct, and some easy syntax to create it 'on the fly', without the need to declare a struct for each combination of return values.
> 
> Instead of writing:
> 
> struct point_t {
>  int a;
>  int b;
> };
> point_t getPoint();
> 
> ..it would be nice if you could write:
> 
> struct {int a;int b;} getPoint();
> 
> Maybe this syntax can be simplified even more, using an implicit struct:
> 
> int, int getPoint();
> 
> Might result in some parsing problems though. In any case, it should be possible to retreive the values in seperate variables (who are not themselves in a similar struct):
> 
> int b;
> // do something with b
> int a;
> a,b = getPoint();
> 
> Note that I don't like calling a function add being able to retreive only
> one of the return values, as mentioned in an earlier example: a =
> getPoint().int;
> First of all there's the ambiguity, but also the fact that this simply
> shouldn't be encouraged. You should retreive all of the values, or none, to
> prevent people calling getPoint().real and .int (with whatever syntax that
> would solve the ambiguity), since the function will be evaluated twice.
> Possibly resulting in a nonsense pair of values, but in any case resulting
> in the code being executed twice!
> 
> L.
> 
> L.

May 23, 2005
I forgot to say...

With this:

> (int,double) func (int param) {
> 	......
> 	......
> 	return (a,b);
> }


And this:

int foo (int a, double d, real c) {
	...
	...
}

We should be allowed to do this:

int a = foo (func(1), e); // 2+1 params !

neat...


May 23, 2005
I like it.

In article <pan.2005.05.23.14.49.16.571845@wanadoo.fr>, G.Vidal says...
>
>
>I forgot to say...
>
>With this:
>
>> (int,double) func (int param) {
>> 	......
>> 	......
>> 	return (a,b);
>> }
>
>
>And this:
>
>int foo (int a, double d, real c) {
>	...
>	...
>}
>
>We should be allowed to do this:
>
>int a = foo (func(1), e); // 2+1 params !
>
>neat...
>
>