This is coming for the D 2.0 beta, and it will need some source code changes. Specifically, for function parameters that are arrays or pointers, start using 'in' for them.

'in' will mean 'scope const final', which means:

final - the parameter will not be reassigned within the function
const - the function will not attempt to change the contents of what is referred to
scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function

For example:

int[] g;

void foo(in int[] a)
{
    a = [1,2];	// error, a is final
    a[1] = 2;   // error, a is const
    g = a;	// error, a is scope
}

Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.

Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

int[] g;
void foo(in int[] a){
    g = a.dup;    // allowed?
}

Frank Benoit wrote:
> int[] g;
> void foo(in int[] a){
>     g = a.dup;    // allowed?
> }

Yes.

Walter Bright wrote:
> This is coming for the D 2.0 beta, and it will need some source code changes. Specifically, for function parameters that are arrays or pointers, start using 'in' for them.
> 
> 'in' will mean 'scope const final', which means:
> 
> final - the parameter will not be reassigned within the function
> const - the function will not attempt to change the contents of what is referred to
> scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function
> 
> For example:
> 
> int[] g;
> 
> void foo(in int[] a)
> {
>     a = [1,2];    // error, a is final
>     a[1] = 2;   // error, a is const
>     g = a;    // error, a is scope
> }
> 
> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
> 
> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

So if you don't use 'in' then the behavior will the the same as not using anything (or using 'in') in D1.0?

--bb

Walter Bright wrote:
> This is coming for the D 2.0 beta, and it will need some source code changes. Specifically, for function parameters that are arrays or pointers, start using 'in' for them.
> 
> 'in' will mean 'scope const final', which means:
> 
> final - the parameter will not be reassigned within the function
> const - the function will not attempt to change the contents of what is referred to
> scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function
> 
> For example:
> 
> int[] g;
> 
> void foo(in int[] a)
> {
>     a = [1,2];    // error, a is final
>     a[1] = 2;   // error, a is const
>     g = a;    // error, a is scope
> }
> 
> Do not use 'in' if you wish to do any of these operations on a parameter. Using 'in' has no useful effect on D 1.0 code, so it'll be backwards compatible.
> 
> Adding in all those 'in's is tedious, as I'm finding out :-(, but I think the results will be worth the effort.

Sounds good to me.  How soon can we expect 2.0beta?

-- Chris Nicholson-Sauls

Walter Bright wrote

> scope - the function will not keep a reference to the parameter's data that will persist beyond the scope of the function

>     g = a;	// error, a is scope

In this example the function assigns to a variable living outside of the scope of the function. Therefore the function does not keep that reference itself---and that rule should not fire.

In addition: if the rule's wording is changed to match that example, then it becomes unclear, whether `writefln( &a)' is allowed because `writefln' might store that reference somewhere---especially via OS in a file, which might be read in later by the calling process.

In case of disallowance that rule would disallow printing too.

-manfred

Walter Bright wrote

> Frank Benoit wrote:
>> int[] g;
>> void foo(in int[] a){
>>     g = a.dup;    // allowed?
>> }
> 
> Yes.

The `.dup'ing an array where a cell contains a reference to the array is allowed too?

alias void* T;
T[] a;
void main(){
  T[] g; g.length= 1;
  g[0]=&g;
  void f( in T[] p){
    a= p.dup;
  }
}

That would contradict the given rule.

-manfred

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> Frank Benoit wrote:
>>> int[] g;
>>> void foo(in int[] a){
>>>     g = a.dup;    // allowed?
>>> }
>> Yes.
> 
> The `.dup'ing an array where a cell contains a reference to the array is allowed too?
> 
> alias void* T;
> T[] a;
> void main(){
>   T[] g; g.length= 1;
>   g[0]=&g;
>   void f( in T[] p){
>     a= p.dup;
>   }
> }
> 
> That would contradict the given rule.

I don't understand. What rule is being violated, and how?

Bill Baxter wrote:
> So if you don't use 'in' then the behavior will the the same as not using anything (or using 'in') in D1.0?

Right - except that you won't be able to past string literals to them (as string literals will be const).

Manfred Nowak wrote:
> Walter Bright wrote
> 
>> scope - the function will not keep a reference to the parameter's
>> data that will persist beyond the scope of the function
> 
>>     g = a;	// error, a is scope
> 
> In this example the function assigns to a variable living outside of the scope of the function. Therefore the function does not keep that reference itself---and that rule should not fire.

Since it's storing a reference that will "persist beyond the scope of the function", it's illegal.

> In addition: if the rule's wording is changed to match that example, then it becomes unclear, whether `writefln( &a)' is allowed because `writefln' might store that reference somewhere---especially via OS in a file, which might be read in later by the calling process.
> 
> In case of disallowance that rule would disallow printing too.

Making copies is allowed.