www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - param2 = param1

reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
Is there a reason why template parameters can default to other 
template parameters, but not regular parameters? For instance:

     // OK
     int foo(int x, int y = x)()
     {
         return x*y;
     }

     // Not OK
     int foo(int x, int y = x)
     {
         return x*y;
     }

When I noticed this it seemed arbitrary, but maybe there's a 
reason?
Aug 26 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Luís Marques:


 Is there a reason why template parameters can default to other 
 template parameters, but not regular parameters? For instance:

     // OK
     int foo(int x, int y = x)()
     {
         return x*y;
     }

     // Not OK
     int foo(int x, int y = x)
     {
         return x*y;
     }

 When I noticed this it seemed arbitrary, but maybe there's a 
 reason?


Do you have some use cases for this?

Bye,
bearophile
Aug 27 2013
parent reply =?UTF-8?B?Ikx1w61z?= Marques" <luis luismarques.eu> writes:
On Tuesday, 27 August 2013 at 11:09:01 UTC, bearophile wrote:

 Do you have some use cases for this?


No, not at the moment. I was just wondering if there was a reason 
for what seemed an arbitrary difference between template 
parameters and normal parameters.
Aug 27 2013
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 27, 2013 21:33:06 =?UTF-8?B?Ikx1w61z?=.Marques 
<luis luismarques.eu> puremagic.com wrote:

 On Tuesday, 27 August 2013 at 11:09:01 UTC, bearophile wrote:

 Do you have some use cases for this?


 
 No, not at the moment. I was just wondering if there was a reason
 for what seemed an arbitrary difference between template
 parameters and normal parameters.


Not that I'm aware of. I'd file a bug (or at least an enhancement request) on 
it on the grounds we should be consistent unless there's a good reason not to 
be, and I'm not aware of any reason for this particular inconsistency (though 
honestly, I wouldn't have expected it to work in either case - if it can, 
great, but I would have just assumed that it wouldn't).

- Jonathan M Davis
Aug 27 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2013 12:47 PM, Jonathan M Davis wrote:

 On Tuesday, August 27, 2013 21:33:06 =?UTF-8?B?Ikx1w61z?=.Marques
 <luis luismarques.eu> puremagic.com wrote:

 On Tuesday, 27 August 2013 at 11:09:01 UTC, bearophile wrote:

 Do you have some use cases for this?


 No, not at the moment. I was just wondering if there was a reason
 for what seemed an arbitrary difference between template
 parameters and normal parameters.




No reason. It simply never occurred to anyone. I've never heard of anyone 
wanting this in all my years of C, C++, and D.


 Not that I'm aware of. I'd file a bug (or at least an enhancement request) on
 it on the grounds we should be consistent unless there's a good reason not to
 be, and I'm not aware of any reason for this particular inconsistency (though
 honestly, I wouldn't have expected it to work in either case - if it can,
 great, but I would have just assumed that it wouldn't).


I'd reject an enhancement request for this unless someone could demonstrate 
significant utility for it.
Aug 27 2013
next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Tuesday, August 27, 2013 12:56:12 Walter Bright wrote:

 Not that I'm aware of. I'd file a bug (or at least an enhancement request)
 on it on the grounds we should be consistent unless there's a good reason
 not to be, and I'm not aware of any reason for this particular
 inconsistency (though honestly, I wouldn't have expected it to work in
 either case - if it can, great, but I would have just assumed that it
 wouldn't).


 
 I'd reject an enhancement request for this unless someone could demonstrate
 significant utility for it.


I'd argue for it simply on the grounds that we try and be consistent, and 
having it work with function arguments and not template arguments is arbitrary 
and inconsistent. But other than that, I'm not sure that I care, as it's not 
something that I've ever needed to do with either function arguments or 
template arguments.

- Jonathan M Davis
Aug 27 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2013 1:04 PM, Jonathan M Davis wrote:

 I'd argue for it simply on the grounds that we try and be consistent, and
 having it work with function arguments and not template arguments is arbitrary
 and inconsistent. But other than that, I'm not sure that I care, as it's not
 something that I've ever needed to do with either function arguments or
 template arguments.


Above all, D needs to be useful. Implementing complex features that have no 
known purpose is counterproductive.
Aug 27 2013
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Aug 27, 2013 at 12:56:12PM -0700, Walter Bright wrote:

 On 8/27/2013 12:47 PM, Jonathan M Davis wrote:

On Tuesday, August 27, 2013 21:33:06 =?UTF-8?B?Ikx1w61z?=.Marques
<luis luismarques.eu> puremagic.com wrote:

On Tuesday, 27 August 2013 at 11:09:01 UTC, bearophile wrote:

Do you have some use cases for this?


No, not at the moment. I was just wondering if there was a reason
for what seemed an arbitrary difference between template
parameters and normal parameters.




 
 No reason. It simply never occurred to anyone. I've never heard of
 anyone wanting this in all my years of C, C++, and D.


TBH I've never heard of anyone wanting normal (non-template) parameters
to default to another parameter either. D is the first language I know
that has such a feature.



Not that I'm aware of. I'd file a bug (or at least an enhancement
request) on it on the grounds we should be consistent unless there's
a good reason not to be, and I'm not aware of any reason for this
particular inconsistency (though honestly, I wouldn't have expected
it to work in either case - if it can, great, but I would have just
assumed that it wouldn't).


 
 I'd reject an enhancement request for this unless someone could
 demonstrate significant utility for it.


What was the original rationale for normal parameters to be able to
default to another parameter?


T

-- 
Why is it that all of the instruments seeking intelligent life in the universe
are pointed away from Earth? -- Michael Beibl
Aug 27 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 8/27/2013 1:05 PM, H. S. Teoh wrote:

 TBH I've never heard of anyone wanting normal (non-template) parameters
 to default to another parameter either. D is the first language I know
 that has such a feature.


It was implemented because it was necessary for many templates.
Aug 27 2013
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 08/27/2013 09:56 PM, Walter Bright wrote:>

 No reason. It simply never occurred to anyone. ...


It's just too easy to work around using overloads in the usual case to 
be annoying enough for opening an enhancement/bug report.


 I'd reject an enhancement request for this


I guess then you'll see it as a non-standard extension at some point.
Arbitrary limitations tend to irk certain compiler developers more than 
others. :o)


 unless someone could demonstrate significant utility for it.


- Safe alloca wrapper using the alloca default argument hack together 
with this. (i.e. bearophile's dynamically-sized strongly typed 
stack-based arrays.)

- Default arguments based on aggregate members.

(This second use case, is just convenience, it avoids wrapper functions. 
However this is true for any, even existing, use case except using 
default arguments as a poor man's replacement for hygienic macros.)


( - Another plus is that the slight change of name lookup implied by 
this change is also handy for later introduction of dependent types. :-) )
Aug 27 2013
parent "Tove" <tove fransson.se> writes:
On Tuesday, 27 August 2013 at 21:21:31 UTC, Timon Gehr wrote:

 - Safe alloca wrapper using the alloca default argument hack 
 together with this. (i.e. bearophile's dynamically-sized 
 strongly typed stack-based arrays.)


Oh Yes please! I've been waiting for this for a long time, there
even was an enhancement request written to facilitate the alloca
default argument hack!

http://d.puremagic.com/issues/show_bug.cgi?id=8075
Aug 28 2013
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-08-27 21:56, Walter Bright wrote:


 No reason. It simply never occurred to anyone. I've never heard of
 anyone wanting this in all my years of C, C++, and D.


void foo (ubyte[] source, ubyte[] destination = source);

Do some operation, by default override "source":

void scale (int width, int height = width);


 I'd reject an enhancement request for this unless someone could
 demonstrate significant utility for it.


So consistency is not a good argument?

-- 
/Jacob Carlborg
Aug 28 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/28/2013 12:16 AM, Jacob Carlborg wrote:

 On 2013-08-27 21:56, Walter Bright wrote:


 No reason. It simply never occurred to anyone. I've never heard of
 anyone wanting this in all my years of C, C++, and D.


 void foo (ubyte[] source, ubyte[] destination = source);

 Do some operation, by default override "source":

 void scale (int width, int height = width);


Is this really a problem that needs solving?



 I'd reject an enhancement request for this unless someone could
 demonstrate significant utility for it.


 So consistency is not a good argument?


Is it really consistent if you have to add a new section in the documentation 
explaining it?
Aug 28 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-08-28 23:51, Walter Bright wrote:


 Is this really a problem that needs solving?


It's not that important. You asked for use cases, I showed a couple.


 Is it really consistent if you have to add a new section in the
 documentation explaining it?


That sounds like the documentation is not very well structured. Either 
this is missing from the documentation, and should be added, or it 
should already be documented somewhere. If it is already documented, and 
documented for templates, it should be moved to a section covering 
arguments both for templates and regular functions.

So yes, possibly depending on how the documentation currently look like.

BTW, if I recall correctly "consistency" is usually one of your 
arguments for doing, or not doing, something.

-- 
/Jacob Carlborg
Aug 28 2013
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 8/27/13, <luis luismarques.eu>" puremagic.com <"\"Lu=EDs".Marques"> wrot=
e:

      // Not OK
      int foo(int x, int y =3D x)
      {
          return x*y;
      }


Personally I think a much more useful feature would be (and this
doesn't block this feature but it's related to default arguments):

struct S
{
    void foo(int x =3D this.y)
    {
    }

    int y;
}
Aug 27 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-08-27 23:51, Andrej Mitrovic wrote:


 Personally I think a much more useful feature would be (and this
 doesn't block this feature but it's related to default arguments):

 struct S
 {
      void foo(int x = this.y)
      {
      }

      int y;
 }


I agree, I've wanted this a couple of times.

-- 
/Jacob Carlborg
Aug 28 2013
prev sibling parent "Yota" <yotaxp thatGoogleMailThing.com> writes:
On Tuesday, 27 August 2013 at 21:51:48 UTC, Andrej Mitrovic wrote:

 On 8/27/13, <luis luismarques.eu>" puremagic.com 
 <"\"Luís".Marques"> wrote:

      // Not OK
      int foo(int x, int y = x)
      {
          return x*y;
      }


 Personally I think a much more useful feature would be (and this
 doesn't block this feature but it's related to default 
 arguments):

 struct S
 {
     void foo(int x = this.y)
     {
     }

     int y;
 }


I used to do something similar to that in another language.  
Something like...

void toggle(bool newState = !this.state) { this.state = newState; 
}

A function that could set state to a given value, or toggle it if 
omitted.  Then again, that language didn't have overloading at 
all.

Another example, but with more complex processing.
void speak(string msg, bool bypassMute = 
this.channel.isAdmin(this.username)) { ... }
Aug 28 2013