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.

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

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

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;
}

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) ); ???

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!

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!

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..

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.

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!