View mode: basic / threaded / horizontal-split · Log in · Help
May 23, 2005
Re: NEAT
Walter is not afraid to do new things, and what youve suggested can be
implemented with structs. So there.

In article <pan.2005.05.23.14.45.22.80514@wanadoo.fr>, G.Vidal says...
>
>
>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
Re: NEAT
In article <pan.2005.05.23.14.45.22.80514@wanadoo.fr>, G.Vidal says...
>
>
>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.

Not "new" really--this is a feature of Lua, and of other languages I'm sure.  It
does beat template-based tuples for this purpose.  Perhaps a 2.0 feature?


Sean
May 24, 2005
Re: return-type function overloading
"Regan Heath" <regan@netwin.co.nz> wrote in message news:opsq64r6tt23k2f5@nrage.netwin.co.nz...
> 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

Okay, not sure whether it was a typo, a word I'm unfamilliar with, or an abbreviated word, but
one way or the other, I have to ask (because I can't guess with any reasonable degree of certainty)...
what was meant by the word "soln" in that context?

TZ
May 24, 2005
Re: return-type function overloading
"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d6s2ki$l2v$1@digitaldaemon.com...
>
> > 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.
>
>

Actually, yes... it's a good example of something that would have to
be "dealt with" but I see two simple possibilities.

The first is to simply define the standard as allowing no more than
a single representative of any specific return value type.
This could be justified by deciding that the "main reason" for allowing
multiple return values is to facilitate a means of allowing a function to
return multiple types.

The second would be to recognize that the return values are an ordered set
and to pass them to an assignment in order, discarding any return values that are
not assigned.

For example...

void main()
{
 real, real, int, char, int[], char x() { return 9.0,1.2;}
 printf("___%d___%g___",x);
 real b, c ;int d, e; char f, g; int[] h;
 b,c = x;
   //first two return parameters
 b = x;
   //very first return parameter
 d,f,g = x;
   // int return parameter, and both char return parameters, in order
 f,h = x;
   // first char return parameter, and the last (int[]) return parameter
 g,h,f = x
   // first char return parameter is assigned to g,
   // second char return parameter is assigned to f,
   // and int[] return parameter is assigned to h
 f,g,h = x;     // error
   // illegal, because the there is no int[] type return after the second char type return value,
   // so there is no matching return parameter for h.
 d,e = x;    // error
   // illegal because there isn't a second int type return parameter to assign to e.
 d,b = x    // error
   // illegal, because the there is real return parameter after the int return parameter,
   // so there is no matching return parameter for b,
   // because they were requested in the wrong order.
}

TZ
May 24, 2005
Re: return-type function overloading
On Mon, 23 May 2005 23:09:22 -0500, TechnoZeus <TechnoZeus@PeoplePC.com>  
wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message  
> news:opsq64r6tt23k2f5@nrage.netwin.co.nz...
>> 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
>
> Okay, not sure whether it was a typo, a word I'm unfamilliar with, or an  
> abbreviated word, but
> one way or the other, I have to ask (because I can't guess with any  
> reasonable degree of certainty)...
> what was meant by the word "soln" in that context?

"soln" == "solution"

Regan
May 24, 2005
Re: return-type function overloading
In article <opsq9rynem23k2f5@nrage.netwin.co.nz>, Regan Heath says...
>
>On Mon, 23 May 2005 23:09:22 -0500, TechnoZeus <TechnoZeus@PeoplePC.com>  
>wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message  
>> news:opsq64r6tt23k2f5@nrage.netwin.co.nz...
>>> 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
>>> >

My 2nd proposition was to remove all implicit casting from parameters and return
types if the function had more than one return type that it was overloaded upon.
Only by being completely explicit can we eliminate ambiguity.

>>> > 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
>>
>> Okay, not sure whether it was a typo, a word I'm unfamilliar with, or an  
>> abbreviated word, but
>> one way or the other, I have to ask (because I can't guess with any  
>> reasonable degree of certainty)...
>> what was meant by the word "soln" in that context?
>
>"soln" == "solution"
>
>Regan

Regards,
James Dunne
May 24, 2005
Re: NEAT
> (int,double) func (int param) {

Nice syntax! I like it.
May 24, 2005
Re: NEAT
>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.

There are _so_ many languages that have tupls build in with exactly the same
syntax, so what is "crazy" about it?
May 24, 2005
Re: NEAT
>Walter is not afraid to do new things, and what youve suggested can be
>implemented with structs. So there.

Loops can be implemented with gotos. So let's remove them.
May 24, 2005
Re: NEAT
> There are _so_ many languages that have tupls build in with exactly the same
> syntax, so what is "crazy" about it?

What I meant by "crazy" is "totally different from the C/C++/C#/Java
syntaxes"

I'm just tired of seeing so many ideas from so many people and finally
there's no response from the D compiler programmer.

So what are we suppose to think ? He reads them and is still thinking
about it, reads and thinks the idea is bad, or maybe he doesn't read them
at all, how can we know ?

If he doesn't agree with the idea, we don't even know why. 
Maybe there should be more programmers for D.
2 3 4 5 6 7 8
Top | Discussion index | About this forum | D home