Thread overview | ||||||
---|---|---|---|---|---|---|
|
November 28, 2014 Dynamic array head const in library code? | ||||
---|---|---|---|---|
| ||||
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 |
November 28, 2014 Re: Dynamic array head const in library code? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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?
|
November 28, 2014 Re: Dynamic array head const in library code? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dominikus Dittes Scherkl | 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
|
November 28, 2014 Re: Dynamic array head const in library code? | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | 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.
|
Copyright © 1999-2021 by the D Language Foundation