View mode: basic / threaded / horizontal-split · Log in · Help
January 14, 2013
Function scope arguments
Maybe this thread shows the need for some design work, see the 
comments by Hara:

http://d.puremagic.com/issues/show_bug.cgi?id=8695

What's the meaning of "in" function arguments? What are the 
purposes of "scope" for function arguments that contain 
indirections, and how to implement that?

Bye,
bearophile
January 14, 2013
Re: Function scope arguments
On 01/14/2013 06:52 PM, bearophile wrote:
> Maybe this thread shows the need for some design work, see the comments
> by Hara:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8695
>
> What's the meaning of "in" function arguments? What are the purposes of
> "scope" for function arguments that contain indirections, and how to
> implement that?
>
> Bye,
> bearophile

'in' is 'const scope'.

'scope' is supposed to restrict escaping references, but it is not 
entirely clear what that means, and how to make it powerful enough. Eg. 
what if part of a structure can be freely escaped, such as the contents 
of an array of Objects, but not the array itself? I'd argue that 
indirections in parameters should not be covered by 'scope', because it 
is not something that is transitive. (the opposite would be)

Furthermore, there is the issue of how to treat 'ref' parameters.

Also, we may want to use 'scope' to annotate struct fields in some way, 
so that structs can capture scope parameters that are ensured at the 
call site to live at least as long as the struct instance.

An implementiation should use flow (and maybe lifetime) analysis.
January 15, 2013
Re: Function scope arguments
On 2013-01-15 00:07, Timon Gehr wrote:

> 'in' is 'const scope'.
>
> 'scope' is supposed to restrict escaping references, but it is not
> entirely clear what that means, and how to make it powerful enough. Eg.
> what if part of a structure can be freely escaped, such as the contents
> of an array of Objects, but not the array itself? I'd argue that
> indirections in parameters should not be covered by 'scope', because it
> is not something that is transitive. (the opposite would be)
>
> Furthermore, there is the issue of how to treat 'ref' parameters.
>
> Also, we may want to use 'scope' to annotate struct fields in some way,
> so that structs can capture scope parameters that are ensured at the
> call site to live at least as long as the struct instance.
>
> An implementiation should use flow (and maybe lifetime) analysis.

For delegates "scope" indicates the delegate is not a real closure and 
won't capture any variables on the heap.

-- 
/Jacob Carlborg
January 15, 2013
Re: Function scope arguments
On Monday, 14 January 2013 at 17:52:32 UTC, bearophile wrote:
> Maybe this thread shows the need for some design work, see the 
> comments by Hara:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=8695
>
> What's the meaning of "in" function arguments? What are the 
> purposes of "scope" for function arguments that contain 
> indirections, and how to implement that?
>
> Bye,
> bearophile

Well I think about it a lot, it is unclear what is the solution, 
but here is how I see it :

stack variable as marked as local.

value marked local are considered scope in any inner scope.
values marked local can be passed to function by value or via 
scope argument.
values marked scope can be passed to function by value or via 
scope argument.

void foo() {
    int a; // a is local.

    {
        // a is scope here
    }
}

Everything accessed throw a scope value is scope.
scope are not referable throw any non scope.
local are not referable to scope.

each scope declaration introduce a new scope. different scope can 
never refers each others.

void foo(scope A a, scope B b) {
    // a and b are in different scopes.
    a.memeber; // Is in the same scope as a, but not as b.

    C c; // c is local.
    D d; // ditto.

    {
        // c and d are in the same scope. a and b are in 
different scope.
        c.member = d; // OK
        c.member = a; // Error.
    }
}

I still have some trouble to figure out the proper definition of 
it. And what can't be defined clearly is probably not understood 
enough to create a feature.
January 15, 2013
Re: Function scope arguments
deadalnix:

> I still have some trouble to figure out the proper definition 
> of it. And what can't be defined clearly is probably not 
> understood enough to create a feature.

While "scope" is probably not the most important feature to work 
now in D (const/immutable issues, and shared issues are possibly 
more important), it's one of the important unfinished parts of D.

It needs a design, and later a partial implementation. Being a 
core language issue I think "scope" is more important than 
optimization issues, like this one:

https://github.com/D-Programming-Language/dmd/commit/4b139c0a217ccbf3c71a0d993eb6e3556254de60

Bye,
bearophile
January 15, 2013
Re: Function scope arguments
On 01/15/13 00:07, Timon Gehr wrote:
> 'scope' is supposed to restrict escaping references, but it is not entirely clear what that means, and how to make it powerful enough. Eg. what if part of a structure can be freely escaped, such as the contents of an array of Objects, but not the array itself? I'd argue that indirections in parameters should not be covered by 'scope', because it is not something that is transitive. (the opposite would be)

A non-transitive scope would not be very useful. Eg. a 'scope' arg could
never refer to a stack object - which is the main advantage of having 'scope'.
Introducing a second kind of top-level-scope would probably complicate the
language too much.

> Furthermore, there is the issue of how to treat 'ref' parameters.

Different problem - lifetime. One approach would be to disallow escaping
them (which in this case includes returning them) unless the compiler is
able to do the right - ie the body of the function is available. Somewhat
unorthodox, but could work. (The problem are not the trivial cases; it's the
ones where the compiler has no idea which ref is escaped/returned at runtime)

artur
January 15, 2013
Re: Function scope arguments
On Tuesday, 15 January 2013 at 10:58:17 UTC, Artur Skawina wrote:
> Different problem - lifetime. One approach would be to disallow 
> escaping
> them (which in this case includes returning them) unless the 
> compiler is
> able to do the right - ie the body of the function is 
> available. Somewhat
> unorthodox, but could work. (The problem are not the trivial 
> cases; it's the
> ones where the compiler has no idea which ref is 
> escaped/returned at runtime)
>

The compiler should assume they may escape unless scope is 
specified.
January 15, 2013
Re: Function scope arguments
On 01/15/13 12:48, deadalnix wrote:
> On Tuesday, 15 January 2013 at 10:58:17 UTC, Artur Skawina wrote:
>> Different problem - lifetime. One approach would be to disallow escaping
>> them (which in this case includes returning them) unless the compiler is
>> able to do the right - ie the body of the function is available. Somewhat
>> unorthodox, but could work. (The problem are not the trivial cases; it's the
>> ones where the compiler has no idea which ref is escaped/returned at runtime)
>>
> 
> The compiler should assume they may escape unless scope is specified.

This is about /avoiding/ "hidden" heap allocations as much as possible. Having
functions with 'ref' and 'auto-ref' args always trigger them is not ideal.

'lazy' args are already problematic enough. (there's currently no way to mark
them as non-escaping, the compiler has to assume that the do -> the result is
that they /always/ cause heap allocations and you have to use explicit scoped
delegates instead, losing the syntax advantages)

artur
January 15, 2013
Re: Function scope arguments
Artur Skawina:

> 'lazy' args are already problematic enough. (there's currently 
> no way to mark them as non-escaping,

A future "scope lazy" annotation?

Bye,
bearophile
January 15, 2013
Re: Function scope arguments
On 01/15/2013 01:44 PM, Artur Skawina wrote:
> On 01/15/13 12:48, deadalnix wrote:
>> On Tuesday, 15 January 2013 at 10:58:17 UTC, Artur Skawina wrote:
>>> Different problem - lifetime. One approach would be to disallow escaping
>>> them (which in this case includes returning them) unless the compiler is
>>> able to do the right - ie the body of the function is available. Somewhat
>>> unorthodox, but could work. (The problem are not the trivial cases; it's the
>>> ones where the compiler has no idea which ref is escaped/returned at runtime)
>>>
>>
>> The compiler should assume they may escape unless scope is specified.
>
> This is about /avoiding/ "hidden" heap allocations as much as possible. Having
> functions with 'ref' and 'auto-ref' args always trigger them is not ideal.
>
> 'lazy' args are already problematic enough. (there's currently no way to mark
> them as non-escaping, the compiler has to assume that the do -> the result is
> that they /always/ cause heap allocations and you have to use explicit scoped
> delegates instead, losing the syntax advantages)
>
> artur
>

Actually lazy args are implicitly 'scope' and never allocate.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home