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 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 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 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 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
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 next sibling parent =?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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next 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
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 next sibling 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 "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