www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: RFC, ensureHeaped

reply bearophile <bearophileHUGS lycos.com> writes:
Steven Schveighoffer:


 int[] globalargs;
 
 void foo(int[] args...)
 {
     globalargs = args;
 }
 
 void bar()
 {
     foo(1,2,3); // passes stack data to foo.
 }
 ...
 Then you just wasted time duping that argument.  Instead of a defensive  
 dup, what if we had a function ensureHeaped (better name suggestions?)  
 that ensured the data was on the heap?



Another possible solution, this turns some cases of stack assignment into a
syntax error (wrong memory zone assignment error), and turns the undeterminable
ones in a runtime test + optional allocation:

 onheap int[] globalargs;

Another possible solution is to modify the semantics of this kind of arguments
pass, so the code inside the function foo always see an args array allocated on
the heap:

void foo(int[] args...) { // code

You may then add "scope" to restore the original lighter semantics:
void foo(scope int[] args...) { // code

This is safer than the current semantics because the safe design is the
built-in one and the faster is on request.

Bye,
bearophile
Nov 12 2010
next sibling parent reply Pillsy <pillsbury gmail.com> writes:
bearophile wrote:
[...]

 Another possible solution is to modify the semantics of this kind of 
 arguments pass, so the code inside the function foo always see an 
 args array allocated on the heap:




 void foo(int[] args...) { // code




 You may then add "scope" to restore the original lighter semantics:
 void foo(scope int[] args...) { // code




 This is safer than the current semantics because the safe design is 
 the built-in one and the faster is on request.



I don't know how easy it would be, but I *really* like this proposal. It has
one other advantage, in that you can use the `scope` keyword for things other
than varargs, like closures.

Cheers,
Pillsy
Nov 12 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Pillsy:


 bearophile wrote:
 [...]

 Another possible solution is to modify the semantics of this kind of 
 arguments pass, so the code inside the function foo always see an 
 args array allocated on the heap:




 void foo(int[] args...) { // code




 You may then add "scope" to restore the original lighter semantics:
 void foo(scope int[] args...) { // code




 This is safer than the current semantics because the safe design is 
 the built-in one and the faster is on request.



 I don't know how easy it would be,



That looks easy to implement, the compiler doesn't need to be smart to do that.
The other idea of  noheap is harder to implement.



 It has one other advantage, in that you can use the `scope` keyword for things
other than varargs, like closures.



That scope syntax is already supported for closures, and it's partially
implemented (or fully implemented, I am not sure).

Bye,
bearophile
Nov 12 2010
next sibling parent reply Pillsy <pillsbury gmail.com> writes:
bearophile wrote:


 Pillsy:




 It has one other advantage, in that you can use the `scope`
 keyword for things other than varargs, like closures.







 That scope syntax is already supported for closures, and it's partially 
 implemented (or fully implemented, I am not sure).



Oh, cool. I had no idea that `scope` was supported for function arguments at
all.

Cheers,
Pillsy
Nov 12 2010
parent bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 I'm not quite sure how that will work with scope going away though.



This scope will not go away.

Bye,
bearophile
Nov 12 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 12, 2010 13:34:03 Pillsy wrote:

 bearophile wrote:

 Pillsy:



 

 It has one other advantage, in that you can use the `scope`
 keyword for things other than varargs, like closures.



 That scope syntax is already supported for closures, and it's partially
 implemented (or fully implemented, I am not sure).



 Oh, cool. I had no idea that `scope` was supported for function arguments
 at all.



in is actually const scope. So

void func(in Foo foo)


would be

void func(const scope Foo foo)


I'm not quite sure how that will work with scope going away though.

- Jonathan M Davis
Nov 12 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday, November 12, 2010 17:25:31 bearophile wrote:

 Jonathan M Davis:

 I'm not quite sure how that will work with scope going away though.



 This scope will not go away.



What's the difference between this scope and using scope on a local variable?

- Jonathan M Davis
Nov 12 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Fri, 12 Nov 2010 20:33:37 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Friday, November 12, 2010 17:25:31 bearophile wrote:

 Jonathan M Davis:

 I'm not quite sure how that will work with scope going away though.



 This scope will not go away.



 What's the difference between this scope and using scope on a local  
 variable?



All that is going away is scope classes.  All other uses of scope are  
staying.

And even then, I think a scope class will still be supported, it just  
won't allocate on the stack (it will probably be a noop like it is for  
other variable types).

scope means different things in different places.  Currently, in a  
parameter it means that references in the parameter cannot be escaped  
(i.e. assigned to a global variable).  When the compiler sees this on  
delegates, it will avoid allocating a closure when taking the address of a  
local function.  This is essential in opApply loops.

And you know about the scope for classes.  AFAIK, those are really the  
only two behavior-altering uses.  Other than that, I think it's a noop.

-Steve
Nov 15 2010
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 15, 2010 07:28:33 Steven Schveighoffer wrote:

 On Fri, 12 Nov 2010 20:33:37 -0500, Jonathan M Davis <jmdavisProg gmx.com>
 
 wrote:

 On Friday, November 12, 2010 17:25:31 bearophile wrote:

 Jonathan M Davis:

 I'm not quite sure how that will work with scope going away though.



 This scope will not go away.



 What's the difference between this scope and using scope on a local
 variable?



 All that is going away is scope classes.  All other uses of scope are
 staying.
 
 And even then, I think a scope class will still be supported, it just
 won't allocate on the stack (it will probably be a noop like it is for
 other variable types).
 
 scope means different things in different places.  Currently, in a
 parameter it means that references in the parameter cannot be escaped
 (i.e. assigned to a global variable).  When the compiler sees this on
 delegates, it will avoid allocating a closure when taking the address of a
 local function.  This is essential in opApply loops.
 
 And you know about the scope for classes.  AFAIK, those are really the
 only two behavior-altering uses.  Other than that, I think it's a noop.



Thanks. I knew about scope classes and scope statements (e.g. scope(failure) 
...), but I didn't know that scope on a parameter was different from scope 
classes. scope is definitely an over-used keyword IMHO.

- Jonathan M Davis
Nov 15 2010
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 15 Nov 2010 13:36:42 -0500, Jonathan M Davis <jmdavisProg gmx.com>  
wrote:


 On Monday, November 15, 2010 07:28:33 Steven Schveighoffer wrote:

 On Fri, 12 Nov 2010 20:33:37 -0500, Jonathan M Davis  
 <jmdavisProg gmx.com>

 wrote:

 On Friday, November 12, 2010 17:25:31 bearophile wrote:

 Jonathan M Davis:

 I'm not quite sure how that will work with scope going away though.



 This scope will not go away.



 What's the difference between this scope and using scope on a local
 variable?



 All that is going away is scope classes.  All other uses of scope are
 staying.

 And even then, I think a scope class will still be supported, it just
 won't allocate on the stack (it will probably be a noop like it is for
 other variable types).

 scope means different things in different places.  Currently, in a
 parameter it means that references in the parameter cannot be escaped
 (i.e. assigned to a global variable).  When the compiler sees this on
 delegates, it will avoid allocating a closure when taking the address  
 of a
 local function.  This is essential in opApply loops.

 And you know about the scope for classes.  AFAIK, those are really the
 only two behavior-altering uses.  Other than that, I think it's a noop.



 Thanks. I knew about scope classes and scope statements (e.g.  
 scope(failure)
 ...), but I didn't know that scope on a parameter was different from  
 scope
 classes. scope is definitely an over-used keyword IMHO.



Forgot completely about scope(failure|success|exit)...

-Steve
Nov 15 2010
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, November 15, 2010 10:45:06 Steven Schveighoffer wrote:

 Forgot completely about scope(failure|success|exit)...



LOL. Whereas that's almost the only reason that I use the scope keyword -
though 
the fact that it doesn't actually give you the exception means that I don't end 
up using it anywhere near as much as I'd like.

- Jonathan M Davis
Nov 15 2010