www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Optional parameters referring to previous parameters?

reply "Mehrdad" <wfunction hotmail.com> writes:
Is this possible/should it compile?

If not, should I make an enhancement request for it? It's been 
something that would've been useful in a ton of situations for 
me...

void process(R)(R items, size_t maxCount = items.length)
{
}
May 09 2012
next sibling parent "Matt Peterson" <ricochet1k gmail.com> writes:
On Thursday, 10 May 2012 at 00:16:52 UTC, Mehrdad wrote:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been 
 something that would've been useful in a ton of situations for 
 me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

Have you tried it? I bet this isn't possible currently, but do open an enhancement request if it isn't. It's going to be a bit tricky to implement, but I like it.
May 09 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 10 May 2012 at 01:06:31 UTC, Matt Peterson wrote:
 On Thursday, 10 May 2012 at 00:16:52 UTC, Mehrdad wrote:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been 
 something that would've been useful in a ton of situations for 
 me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

Have you tried it? I bet this isn't possible currently, but do open an enhancement request if it isn't. It's going to be a bit tricky to implement, but I like it.

Well I mean of course I tried it (and it didn't work), but I was just making sure I wasn't doing something wrong and that it wasn't recently added or something. Ok I'll make a request for it.
May 09 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
http://d.puremagic.com/issues/show_bug.cgi?id=8075
May 09 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Wed, 09 May 2012 20:16:51 -0400, Mehrdad <wfunction hotmail.com> wrote:

 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been something  
 that would've been useful in a ton of situations for me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

I *love* this idea. Although, what happens if the expression for items is costly? We have to make sure if you do: process(someExpensiveCalculation()); it doesn't turn into: process(someExpensiveCalculation(), someExpensiveCalculation().length); -Steve
May 10 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 10 May 2012 at 11:54:42 UTC, Steven Schveighoffer 
wrote:
 I *love* this idea.

:D
 Although, what happens if the expression for items is costly?  
 We have to make sure if you do:

 process(someExpensiveCalculation());

 it doesn't turn into:

 process(someExpensiveCalculation(), 
 someExpensiveCalculation().length);

It should be evaluated once anyway, since it might have side effects.
May 10 2012
prev sibling next sibling parent reply Mafi <mafi example.org> writes:
Am 10.05.2012 02:16, schrieb Mehrdad:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been something
 that would've been useful in a ton of situations for me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

Solution: void process(R)(R items) { process(items, items.length); } void process(R)(R items, int maxCount); Is such a miminal syntactic sugar addition worth it?
May 10 2012
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 10.05.2012 19:07, schrieb Tove:
 auto my_extended_alloca(size_t size, void* buf=alloca(size))
 {
     return buf;
 }

and whats the difference to? auto my_extended_alloca(size_t size, void* buf) { return alloca(size); } except that you hide the alloca in the interface which can be easily overwritten with malloc or something? auto x = my_extended_alloca( 10, malloc(100) ); ???
May 10 2012
parent dennis luehring <dl.soluz gmx.net> writes:
Am 10.05.2012 19:48, schrieb Tove:
 When used in the parameter list, the alloca() is injected into
 the parent scope.

 Your version doesn't work at all, as the allocation automatically
 ends with the scope of my_extended_alloca() instead of the scope
 of the caller!

ah i see clearly now!
May 10 2012
prev sibling parent Mafi <mafi example.org> writes:
Am 10.05.2012 19:07, schrieb Tove:
 On Thursday, 10 May 2012 at 15:51:08 UTC, Steven Schveighoffer wrote:
 On Thu, 10 May 2012 11:48:25 -0400, Steven Schveighoffer
 <schveiguy yahoo.com> wrote:

 And BTW, it's not just sugar -- you are saving a function call and
 unnecessary code space.

 -Steve

ui, pretty please! I love it too, it would allow this marvelous construct! auto my_extended_alloca(size_t size, void* buf=alloca(size)) { return buf; }

I see: that is an interesting use case!
May 11 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 10 May 2012 at 14:11:32 UTC, Mafi wrote:
 Am 10.05.2012 02:16, schrieb Mehrdad:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been 
 something
 that would've been useful in a ton of situations for me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

Solution: void process(R)(R items) { process(items, items.length); } void process(R)(R items, int maxCount); Is such a miminal syntactic sugar addition worth it?

Yes! That's, like, 80 fewer characters... And it doesn't scale with multiple optional arguments..
May 10 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 10 May 2012 at 14:33:32 UTC, Mehrdad wrote:
 On Thursday, 10 May 2012 at 14:11:32 UTC, Mafi wrote:
 Am 10.05.2012 02:16, schrieb Mehrdad:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's 
 been something
 that would've been useful in a ton of situations for me...

 


with multiple optional arguments..

er, more* characters
May 10 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 10 May 2012 at 14:33:32 UTC, Mehrdad wrote:
 On Thursday, 10 May 2012 at 14:11:32 UTC, Mafi wrote:
 Am 10.05.2012 02:16, schrieb Mehrdad:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's 
 been something
 that would've been useful in a ton of situations for me...

 


with multiple optional arguments..

er, more* characters
May 10 2012
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 5/10/12, Mehrdad <wfunction hotmail.com> wrote:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been
 something that would've been useful in a ton of situations for
 me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

If this is implemented I'd also throw this in: struct Foo { property int x() { return 1; } void process(size_t y = x) { } } It doesn't have to be a property function, it could be a field. But it won't work right now unless "x" is marked static.
May 10 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 May 2012 10:11:35 -0400, Mafi <mafi example.org> wrote:

 Am 10.05.2012 02:16, schrieb Mehrdad:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been something
 that would've been useful in a ton of situations for me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

Solution: void process(R)(R items) { process(items, items.length); } void process(R)(R items, int maxCount); Is such a miminal syntactic sugar addition worth it?

The same could be said for current default arg feature. If it's worth it there, why not here? -Steve
May 10 2012
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 10 May 2012 11:48:25 -0400, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 On Thu, 10 May 2012 10:11:35 -0400, Mafi <mafi example.org> wrote:

 Am 10.05.2012 02:16, schrieb Mehrdad:
 Is this possible/should it compile?

 If not, should I make an enhancement request for it? It's been  
 something
 that would've been useful in a ton of situations for me...

 void process(R)(R items, size_t maxCount = items.length)
 {
 }

Solution: void process(R)(R items) { process(items, items.length); } void process(R)(R items, int maxCount); Is such a miminal syntactic sugar addition worth it?

The same could be said for current default arg feature. If it's worth it there, why not here?

And BTW, it's not just sugar -- you are saving a function call and unnecessary code space. -Steve
May 10 2012
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Thursday, 10 May 2012 at 15:51:08 UTC, Steven Schveighoffer 
wrote:
 On Thu, 10 May 2012 11:48:25 -0400, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 And BTW, it's not just sugar -- you are saving a function call 
 and unnecessary code space.

 -Steve

ui, pretty please! I love it too, it would allow this marvelous construct! auto my_extended_alloca(size_t size, void* buf=alloca(size)) { return buf; }
May 10 2012
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Thursday, 10 May 2012 at 17:41:23 UTC, dennis luehring wrote:
 Am 10.05.2012 19:07, schrieb Tove:
 auto my_extended_alloca(size_t size, void* buf=alloca(size))
 {
    return buf;
 }

and whats the difference to? auto my_extended_alloca(size_t size, void* buf) { return alloca(size); } except that you hide the alloca in the interface which can be easily overwritten with malloc or something? auto x = my_extended_alloca( 10, malloc(100) ); ???

When used in the parameter list, the alloca() is injected into the parent scope. Your version doesn't work at all, as the allocation automatically ends with the scope of my_extended_alloca() instead of the scope of the caller!
May 10 2012
prev sibling next sibling parent "Mehrdad" <wfunction hotmail.com> writes:
On Thursday, 10 May 2012 at 17:07:49 UTC, Tove wrote:
 On Thursday, 10 May 2012 at 15:51:08 UTC, Steven Schveighoffer 
 wrote:
 On Thu, 10 May 2012 11:48:25 -0400, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 And BTW, it's not just sugar -- you are saving a function call 
 and unnecessary code space.

 -Steve

ui, pretty please! I love it too, it would allow this marvelous construct! auto my_extended_alloca(size_t size, void* buf=alloca(size)) { return buf; }

lol, that's exactly why I asked for this..
May 10 2012
prev sibling parent "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Thu, 10 May 2012 19:07:47 +0200, Tove <tove fransson.se> wrote:

 On Thursday, 10 May 2012 at 15:51:08 UTC, Steven Schveighoffer wrote:
 On Thu, 10 May 2012 11:48:25 -0400, Steven Schveighoffer  
 <schveiguy yahoo.com> wrote:

 And BTW, it's not just sugar -- you are saving a function call and  
 unnecessary code space.

 -Steve

ui, pretty please! I love it too, it would allow this marvelous construct! auto my_extended_alloca(size_t size, void* buf=alloca(size)) { return buf; }

I loves that.
May 11 2012