## digitalmars.D - An Orthogonal Const Proposal

• Oskar Linde (47/47) Dec 07 2007 Since everyone is doing it, the peer pressure got too heavy and I just
• Paul Anderson (5/18) Dec 07 2007 I like the orthogonal emphasis of this proposal. Rather than having to d...
• Paul Anderson (5/18) Dec 07 2007 I like the orthogonal emphasis of this proposal. Rather than having to d...
• bearophile (4/6) Dec 07 2007 Your idea starts to be readable. I don't like the syntax enough yet, but...
Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
```Since everyone is doing it, the peer pressure got too heavy and I just
felt I too had to make a const proposal ready to be shot down.  :)

Anyway, here is a very simple orthogonal const proposal that I believe
catches most of the earlier suggestions in a more concise way.

Since the table below probably will become squished by the news reader,

http://www.csc.kth.se/~ol/const.pdf

The same text as in the PDF follows:

== Deﬁnitions
*Values* are physical entities that occupy memory. A value can be either
variable or constant. All values have a type. Examples of values in D are:
- basic types
- structs
- array slices (8 bytes on a 32 bit architecture)
- pointers (4 bytes on a 32 bit architecture)
- class references (4 bytes on a 32 bit architecture)

*References* are values that in some way refer to other values.
References have access modes. In this proposal, for simplicity, there

== Descriptions of earlier D const designs
In the ﬁrst const iteration:
const      sets the read-only access mode
invariant  sets the read-only access mode and deﬁnes the
/target value/ to be constant
ﬁnal       deﬁnes the value to be constant

In the last const iteration:
const      sets the read-only access mode and deﬁnes the
value to be constant
invariant  sets the read-only access mode and deﬁnes the
value to be constant and deﬁnes the target
value to be constant

== New suggested const design
const      deﬁnes the value to be constant
an obvious alternative)

== Comparisons with earlier const iterations

ﬁrst iteration         last iteration            new suggestion
const int *            TailConst!(int *) (?)     in int *
invariant int *        TailInvariant!(int *) (?) const(int) *
ﬁnal invariant(int) *  invariant int *           const const(int) *
const Class            TailConst!(Class) (?)     in Class
ﬁnal const Class       const Class (?)           const in Class
invariant(char)[]      invariant(char)[]         const(char)[]
ﬁnal invariant(char)[] invariant char[]          const const(char)[]

--
Oskar
```
Dec 07 2007
Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
```Oskar Linde Wrote:

Since everyone is doing it, the peer pressure got too heavy and I just
felt I too had to make a const proposal ready to be shot down.  :)

Anyway, here is a very simple orthogonal const proposal that I believe
catches most of the earlier suggestions in a more concise way.

Since the table below probably will become squished by the news reader,

http://www.csc.kth.se/~ol/const.pdf

I like the orthogonal emphasis of this proposal. Rather than having to decide
what "const" means in a particular context, it always means the same thing.
Ditto for "in" (I prefer "readonly").

If these keywords can capture all the varieties of const/invariant that have
been proposed I would vote for it.

I'll take a look at this vs. guslay's list of const meanings and, unless
someone beats me to it, post the results.

Paul
```
Dec 07 2007
Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
```Oskar Linde Wrote:

Since everyone is doing it, the peer pressure got too heavy and I just
felt I too had to make a const proposal ready to be shot down.  :)

Anyway, here is a very simple orthogonal const proposal that I believe
catches most of the earlier suggestions in a more concise way.

Since the table below probably will become squished by the news reader,

http://www.csc.kth.se/~ol/const.pdf

I like the orthogonal emphasis of this proposal. Rather than having to decide
what "const" means in a particular context, it always means the same thing.
Ditto for "in" (I prefer "readonly").

If these keywords can capture all the varieties of const/invariant that have
been proposed I would vote for it.

I'll take a look at this vs. guslay's list of const meanings and, unless
someone beats me to it, post the results.

Paul
```
Dec 07 2007
bearophile <bearophileHUGS lycos.com> writes:
```Oskar Linde:
Anyway, here is a very simple orthogonal const proposal that I believe
catches most of the earlier suggestions in a more concise way.

Your idea starts to be readable. I don't like the syntax enough yet, but I like
its being orthogonal. So I think it can be improved still, keeping it
orthogonal.

Bye,
bearophile
```
Dec 07 2007