Re: param2 = param1
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
Re: param2 = param1
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
Re: param2 = param1
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
Re: param2 = param1
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
Re: param2 = param1
On Tuesday, 27 August 2013 at 21:51:48 UTC, Andrej Mitrovic wrote:
On 8/27/13, l...@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)) { ... }
Re: param2 = param1
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?
Re: param2 = param1
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
Re: param2 = param1
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.
Re: param2 = param1
On Tuesday, August 27, 2013 21:33:06 =?UTF-8?B?Ikx1w61z?=.Marques l...@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
Re: param2 = param1
On 8/27/2013 12:47 PM, Jonathan M Davis wrote: On Tuesday, August 27, 2013 21:33:06 =?UTF-8?B?Ikx1w61z?=.Marques l...@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.
Re: param2 = param1
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
Re: param2 = param1
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 l...@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
Re: param2 = param1
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.
Re: param2 = param1
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.
Re: param2 = param1
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. :-) )
Re: param2 = param1
On 8/27/13, l...@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;
}
