• bearophile (42/42) Nov 28 2014 In D code it's a good idea to set as const/immutable (where
• Dominikus Dittes Scherkl (3/9) Nov 28 2014 Why you don't use static arrays for such a purpose?
• bearophile (6/8) Nov 28 2014 Currently you can't create a static array with a length known
• John Colvin (9/51) Nov 28 2014 I wouldn't call it HeadConst, as that is a very general term.

"bearophile" <bearophileHUGS lycos.com> writes:

In D code it's a good idea to set as const/immutable (where 
possible) all variables that don't need to change, for both 
safety and compiler-enforced code documentation.
In my D functions sometimes I create dynamic arrays that later 
don't have to change length nor to be reassigned, but I have to 
mutate or assign their items. So their length and ptr can be 
const/immutable, unlike the array contents. The D type system 
doesn't allow this.
So is it a good idea to try to add to Phobos a headConst function 
similar to this (only for built-in dynamic arrays) that tries to 
enforce those constraints?



import std.traits, std.range;

struct HeadConst(T) {
     T[] data;
     alias data this;
      property size_t length() const pure nothrow  safe  nogc {
         return data.length;
     }
      disable void opAssign();
}

HeadConst!(ElementType!R) headConst(R)(R arr)
if (isDynamicArray!R) {
     return typeof(return)(arr);
}

void main() {
     import std.stdio;
     auto arr = new int[2].headConst;
     arr[1] = 10;
     arr[1].writeln;
     arr.length.writeln;
     //arr.length = arr.length + 1; // error
     auto b = new int[2];
     //arr = b; // error
     arr[] = b[];
     b = arr;
     arr[] = 1;
     HeadConst!int c = arr;
     HeadConst!int d;
     arr = d; // fail
}

Bye,
bearophile

"Dominikus Dittes Scherkl" writes:

On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote:
 In D code it's a good idea to set as const/immutable (where 
 possible) all variables that don't need to change, for both 
 safety and compiler-enforced code documentation.
 In my D functions sometimes I create dynamic arrays that later 
 don't have to change length nor to be reassigned, but I have to 
 mutate or assign their items.

Why you don't use static arrays for such a purpose?
I thought this is exactly what they are made for, aren't they?

"bearophile" <bearophileHUGS lycos.com> writes:

Dominikus Dittes Scherkl:

 Why you don't use static arrays for such a purpose?
 I thought this is exactly what they are made for, aren't they?

Currently you can't create a static array with a length known 
only at run-time. And passing around a fixed-size arrays has some 
costs.

Bye,
bearophile

"John Colvin" <john.loughran.colvin gmail.com> writes:

On Friday, 28 November 2014 at 10:55:27 UTC, bearophile wrote:
 In D code it's a good idea to set as const/immutable (where 
 possible) all variables that don't need to change, for both 
 safety and compiler-enforced code documentation.
 In my D functions sometimes I create dynamic arrays that later 
 don't have to change length nor to be reassigned, but I have to 
 mutate or assign their items. So their length and ptr can be 
 const/immutable, unlike the array contents. The D type system 
 doesn't allow this.
 So is it a good idea to try to add to Phobos a headConst 
 function similar to this (only for built-in dynamic arrays) 
 that tries to enforce those constraints?



 import std.traits, std.range;

 struct HeadConst(T) {
     T[] data;
     alias data this;
      property size_t length() const pure nothrow  safe  nogc {
         return data.length;
     }
      disable void opAssign();
 }

 HeadConst!(ElementType!R) headConst(R)(R arr)
 if (isDynamicArray!R) {
     return typeof(return)(arr);
 }

 void main() {
     import std.stdio;
     auto arr = new int[2].headConst;
     arr[1] = 10;
     arr[1].writeln;
     arr.length.writeln;
     //arr.length = arr.length + 1; // error
     auto b = new int[2];
     //arr = b; // error
     arr[] = b[];
     b = arr;
     arr[] = 1;
     HeadConst!int c = arr;
     HeadConst!int d;
     arr = d; // fail
 }

 Bye,
 bearophile

I wouldn't call it HeadConst, as that is a very general term.

A common situation for me is where I know the length at 
compile-time, I want to make use of that knowledge (either in a 
template somewhere or in hope of a compiler optimisation) but I 
don't want the memory on the stack. That doesn't necessarily mean 
I don't want to change the pointer though.

There's quite a lot of different possibilities that are useful, a 
small set of utilities to help manage them would be great.