www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The problem with const proposals

reply Gregor Richards <Richards codu.org> writes:
Not a single person on this board (and I mean NO ONE) has a grasp over 
everything that one can reasonably expect const to do. What we need to 
do is construct a complete list of features that the const system ought 
to have, so that any const proposal can be checked against the "good 
clean const fun" checklist. Instead, what we have is suggestion after 
suggestion, each with good points but each with fundamental flaws. We're 
never going to get anywhere like this because nobody knows what everyone 
needs.

Disclaimer: It is of course impossible to make a list that makes 
everyone happy. C'est la vie.

  - Gregor Richards
Dec 07 2007
next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
On Fri, 07 Dec 2007 08:31:43 -0800
Gregor Richards <Richards codu.org> wrote:

 Not a single person on this board (and I mean NO ONE) has a grasp
 over everything that one can reasonably expect const to do. What we
 need to do is construct a complete list of features that the const
 system ought to have, so that any const proposal can be checked
 against the "good clean const fun" checklist. Instead, what we have
 is suggestion after suggestion, each with good points but each with
 fundamental flaws. We're never going to get anywhere like this
 because nobody knows what everyone needs.
 
 Disclaimer: It is of course impossible to make a list that makes 
 everyone happy. C'est la vie.
 
   - Gregor Richards

me too. -- Alexander Panek <alexander.panek brainsware.org>
Dec 07 2007
prev sibling next sibling parent mandel <oh no.es> writes:
On Fri, 07 Dec 2007 08:31:43 -0800, Gregor Richards wrote:

 Not a single person on this board (and I mean NO ONE) has a grasp over
 everything that one can reasonably expect const to do. What we need to
 do is construct a complete list of features that the const system ought
 to have, so that any const proposal can be checked against the "good
 clean const fun" checklist.

Can't someone make a checklist on some wiki? All those different ideas are confusing and time consuming.
Dec 07 2007
prev sibling next sibling parent reply "Craig Black" <cblack ara.com> writes:
"Gregor Richards" <Richards codu.org> wrote in message 
news:fjbshj$2273$1 digitalmars.com...
 Not a single person on this board (and I mean NO ONE) has a grasp over 
 everything that one can reasonably expect const to do. What we need to do 
 is construct a complete list of features that the const system ought to 
 have, so that any const proposal can be checked against the "good clean 
 const fun" checklist. Instead, what we have is suggestion after 
 suggestion, each with good points but each with fundamental flaws. We're 
 never going to get anywhere like this because nobody knows what everyone 
 needs.

 Disclaimer: It is of course impossible to make a list that makes everyone 
 happy. C'est la vie.

  - Gregor Richards

I don't really see what your point is. We should drop const altogether? I agree with your observation in part. However, it is beneficial to discuss and hash out ideas. Discussion helps everyone understand const better. Yes, no single person can grasp all the complexities of const, but perhaps together we can arrive at a better solution.
Dec 07 2007
parent reply Gregor Richards <Richards codu.org> writes:
Craig Black wrote:
 "Gregor Richards" <Richards codu.org> wrote in message 
 news:fjbshj$2273$1 digitalmars.com...
 Not a single person on this board (and I mean NO ONE) has a grasp over 
 everything that one can reasonably expect const to do. What we need to do 
 is construct a complete list of features that the const system ought to 
 have, so that any const proposal can be checked against the "good clean 
 const fun" checklist. Instead, what we have is suggestion after 
 suggestion, each with good points but each with fundamental flaws. We're 
 never going to get anywhere like this because nobody knows what everyone 
 needs.

 Disclaimer: It is of course impossible to make a list that makes everyone 
 happy. C'est la vie.

  - Gregor Richards

I don't really see what your point is. We should drop const altogether? I agree with your observation in part. However, it is beneficial to discuss and hash out ideas. Discussion helps everyone understand const better. Yes, no single person can grasp all the complexities of const, but perhaps together we can arrive at a better solution.

... are we speaking the same language? My point is that we should, as a group, create (or "hash out") a list of concepts that const must encompass, rather than creating syntax proposal after syntax proposal, so that we'll actually have something to test the syntax proposals against. - Gregor Richards
Dec 07 2007
parent "Craig Black" <cblack ara.com> writes:
 ... are we speaking the same language?

 My point is that we should, as a group, create (or "hash out") a list of 
 concepts that const must encompass, rather than creating syntax proposal 
 after syntax proposal, so that we'll actually have something to test the 
 syntax proposals against.

  - Gregor Richards

Sorry I misunderstood you. Yes good idea.
Dec 07 2007
prev sibling next sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= writes:
Gregor Richards wrote:
 Not a single person on this board (and I mean NO ONE) has a grasp over 
 everything that one can reasonably expect const to do. What we need to 
 do is construct a complete list of features that the const system ought 
 to have, so that any const proposal can be checked against the "good 
 clean const fun" checklist. Instead, what we have is suggestion after 
 suggestion, each with good points but each with fundamental flaws. We're 
 never going to get anywhere like this because nobody knows what everyone 
 needs.
 
 Disclaimer: It is of course impossible to make a list that makes 
 everyone happy. C'est la vie.
 
  - Gregor Richards

I think - functionally - most of the proposals so far would suffice. But it would sure be interesting to have a more or less representative coverage measure. From my personal experience with working on a fairly complex codebase (about 500 modules/classes), which was first partially ported from C++ to non-const-D, before 2.0 was out and since then has got const/invariant brought in, my list would roughly be: arrays: const(T)[] const(T[]) tailconst(C)[] const(C[]) T[const(C)] const(T)*[] pointers: const(T)* const(T*) inside structs/classes: tailconst(C) invariant T (C=class, T=any) The same goes for invariant. This is from a quick grep over the code base including some workarounds for things which are currently impossible in that form. The more complex type constructs I've found are only used locally without const or are implicit like in "auto pointerToClassRef = key in assocarray;". Other related things are some invariant classes and const/invariant member functions. Also, in the beginning I occasionally missed non-transitive const, but that has not been a problem since then.
Dec 07 2007
prev sibling next sibling parent reply guslay <guslay gmail.com> writes:
Here is my list so far (examples are just for illustration, I do not propose a
syntax):


1- non-addressable constant value (we can distinguish two conceptual flavors)
    a - constant primive (aka define)
    b - enumeration

2- immutable value type (addressable)
      - current const/invariant (they represent the same thing, don't they?)
        ex. const int x = 42; const S s(0,0);

3- immutable reference type (aka pointer to const data)
    a - reference immutable class
        ex. const C c = new C(0,0);

    b - pointer to immutable value
        ex. const (T)* s; //ptr to const T
        ex. const (T*) s; //const ptr to const T

4- aggregates (arrays etc)
    a - mutable container of const data
        ex. const(T)[]

    b - immutable container of const data
        ex. const(T[])

    c - immutable container of mutable data
        ex. ?? T[const]

5- non-rebindable value
      - pointless, basically covered by 1

6- non-rebindable reference (aka const pointer to data)
    a - to mutable data
        ex. final S* s; final C;

    b - to immutable data
        ex. final const S* s; final const C;


There might be some overlap (eg. between 3b and 6).
Dec 07 2007
next sibling parent reply "Janice Caron" <caron800 googlemail.com> writes:
On 12/7/07, guslay <guslay gmail.com> wrote:
 Here is my list so far

But what is it a list /of/? I ask because item 6a violates const-transitivity, and const-transitivity is itself deemed to be a requirement of the D programming language. Are we compiling a list of conflicting requirement here? My list would be much shorter. It would be that const should be: (1) simple to understand (2) transitive (3) compatible with generic programming ...and that's kind of it, really.
Dec 07 2007
next sibling parent reply Paul Anderson <paul.d.anderson.removethis comcast.andthis.net> writes:
Janice Caron Wrote:

 On 12/7/07, guslay <guslay gmail.com> wrote:
 Here is my list so far

But what is it a list /of/? I ask because item 6a violates const-transitivity, and const-transitivity is itself deemed to be a requirement of the D programming language. Are we compiling a list of conflicting requirement here? My list would be much shorter. It would be that const should be: (1) simple to understand (2) transitive (3) compatible with generic programming ...and that's kind of it, really.

<why can't we all just get along?> I think that guslay's list distills a lot of the discussion here, at least about what people want. I agree that it is a good idea to have such a list to guide our discussion. I agree with Janice that such a list needs to be defined and scrubbed for consistency. Maybe we could have a compiler switch that turns const features and const keywords on and off? </why can't we all just get along?> Paul
Dec 07 2007
parent Christopher Wright <dhasenan gmail.com> writes:
Paul Anderson wrote:
 Maybe we could have a compiler switch that turns const features and const
keywords on and off?

I want to compile my app with your const-a-f-o library and someone else's const-b-t-r library. I'm screwed. Until DMD can create good precompiled libraries, that is.
Dec 07 2007
prev sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= writes:
Janice Caron wrote:
 On 12/7/07, guslay <guslay gmail.com> wrote:
 Here is my list so far

But what is it a list /of/? I ask because item 6a violates const-transitivity, and const-transitivity is itself deemed to be a requirement of the D programming language. Are we compiling a list of conflicting requirement here? My list would be much shorter. It would be that const should be: (1) simple to understand (2) transitive (3) compatible with generic programming ...and that's kind of it, really.

I'd add (4) nice, intuitive syntax (as far as that's possible)
Dec 07 2007
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Sönke Ludwig wrote:
 I'd add (4) nice, intuitive syntax (as far as that's possible)

Unfortunately, that's not a design requirement that can be tested.
Dec 07 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Walter Bright wrote:
 Sönke Ludwig wrote:
 I'd add (4) nice, intuitive syntax (as far as that's possible)

Unfortunately, that's not a design requirement that can be tested.

I think it's also covered Janice's #(1): simple to understand.
Dec 07 2007
prev sibling parent Graham St Jack <Graham.StJack internode.on.net> writes:
On Fri, 07 Dec 2007 12:59:52 -0500, guslay wrote:

 Here is my list so far (examples are just for illustration, I do not
 propose a syntax):
 
 
 1- non-addressable constant value (we can distinguish two conceptual
 flavors)
     a - constant primive (aka define)
     b - enumeration
 
 2- immutable value type (addressable)
       - current const/invariant (they represent the same thing, don't
       they?)
         ex. const int x = 42; const S s(0,0);
 
 3- immutable reference type (aka pointer to const data)
     a - reference immutable class
         ex. const C c = new C(0,0);
 
     b - pointer to immutable value
         ex. const (T)* s; //ptr to const T
         ex. const (T*) s; //const ptr to const T
 
 4- aggregates (arrays etc)
     a - mutable container of const data
         ex. const(T)[]
 
     b - immutable container of const data
         ex. const(T[])
 
     c - immutable container of mutable data
         ex. ?? T[const]
 
 5- non-rebindable value
       - pointless, basically covered by 1
 
 6- non-rebindable reference (aka const pointer to data)
     a - to mutable data
         ex. final S* s; final C;
 
     b - to immutable data
         ex. final const S* s; final const C;
 
 
 There might be some overlap (eg. between 3b and 6).

Don't forget const and invariant methods and all that goes with them.
Dec 11 2007
prev sibling next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Gregor Richards wrote:
 Not a single person on this board (and I mean NO ONE) has a grasp over 
 everything that one can reasonably expect const to do. What we need to 
 do is construct a complete list of features that the const system ought 
 to have, so that any const proposal can be checked against the "good 
 clean const fun" checklist. Instead, what we have is suggestion after 
 suggestion, each with good points but each with fundamental flaws. We're 
 never going to get anywhere like this because nobody knows what everyone 
 needs.

It's not fair injecting sense into this <g>. I've certainly spent the last year discovering what doesn't work because of this or that. It does pay to now and then go back and remember exactly what problem one is trying to solve in the first place.
Dec 07 2007
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
In developing D, I've found it very helpful to think in terms of 
"axioms", which are fundamental principles that one can test a design 
against. If any tests fail, then one must change the design, or perhaps 
one discovers that the axioms aren't really axioms at all. It's 
analogous to mathematical axioms. In fact, Andrei pointed out that if we 
adhere to axioms, then we can do mathematical proofs about D, such as 
proof of correctness.

For example, in physics we have the axioms:

1) entropy always increases
2) mass and energy are conserved

so if we have a fellow with a new perpetual motion machine design, we 
automatically know he's a crackpot.

In economics, we have the axiom:

1) There ain't no such thing as a free lunch.

and any economic theory that produces something for nothing is a 
crackpot theory.

So, what are our axioms for const/invariant?

1) Const/invariant are transitive.
2) Any type T can be wrapped inside a struct S, and that S can be made 
to behave as a typedef for type T.
3) The contents of invariant types, once constructed, can never change.
4) The contents of const types, once constructed, can never be changed 
through those const contents.
5) For any type T, we can construct a const(T) or an invariant(T) 
without knowing anything about T.
Dec 07 2007
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Walter Bright Wrote:
 So, what are our axioms for const/invariant?
 
 1) Const/invariant are transitive.
 2) Any type T can be wrapped inside a struct S, and that S can be made 
 to behave as a typedef for type T.
 3) The contents of invariant types, once constructed, can never change.
 4) The contents of const types, once constructed, can never be changed 
 through those const contents.
 5) For any type T, we can construct a const(T) or an invariant(T) 
 without knowing anything about T.

I'd like to see a list of goals that drive axiom development. The list below includes some of the stuff posted by others plus additional stuff. (a) simple to understand (b) nice, intuitive syntax (c) compatible with generic programming (d) compatible with functional programming (e) compatible with compiler optimization (f) const guarantees for API's I'm not sure where axiom 2 comes from. I believe the requirement for invariant comes in from (d) and (e) while the requirement for const comes from (f). I'd love to see "const X" == "const(X)" as an axiom ;) In the past, when considering const, I found it very helpful to think about when implicit casts to (scoped) const/invariant are valid. I believe that in the current design, there's no way for the compiler to guarantee that a cast to invariant is valid because there's never a guarantee that a non-invariant bit of data will be written to by something else. IMHO, having well defined cases when casting is safe should be another requirement.
Dec 07 2007
parent Walter Bright <newshound1 digitalmars.com> writes:
Jason House wrote:
 I'd love to see "const X" == "const(X)" as an axiom ;)

I've tried to avoid having a specific syntax as an axiom, because ideally the syntax should be derivable from the axioms.
 I
 believe that in the current design, there's no way for the compiler
 to guarantee that a cast to invariant is valid because there's never
 a guarantee that a non-invariant bit of data will be written to by
 something else.

There have been some papers written about this. Unfortunately, the various designs for it just aren't workable.
Dec 07 2007
prev sibling next sibling parent "Janice Caron" <caron800 googlemail.com> writes:
On 12/7/07, Jason House <jason.james.house gmail.com> wrote:
 I'm not sure where axiom 2 comes from.

But it's certainly a desirable one. I'd prioritise axiom 2 any day. Not happy with type T? Well, wrap it in a struct, add a few functions, and viola - a new type that's just like a T, only better in whatever ways you care to code. It's a good axiom. ...and it impacts tail-constness, which is why Walter listed it in this thread. In order to comply with the axiom, it must be possible to make tailconst( struct { T }) behave like struct { tailconst(T) } and that's something which has not been addressed by any syntax proposal so far, /except/ for Andrei's TailConst!() template. ...which is one reason why I like the template idea.
Dec 07 2007
prev sibling parent Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
Walter Bright wrote:

 So, what are our axioms for const/invariant?
 
 1) Const/invariant are transitive.
 2) Any type T can be wrapped inside a struct S, and that S can be made 
 to behave as a typedef for type T.
 3) The contents of invariant types, once constructed, can never change.
 4) The contents of const types, once constructed, can never be changed 
 through those const contents.
 5) For any type T, we can construct a const(T) or an invariant(T) 
 without knowing anything about T.

Those "axioms" may a bit too specific and already locks the design into something sub-optimal. I think it would be better to specify design requirements that better show what issues need to be handled. My orthogonal const proposal would handle most of those without problem, and does away with the overlapping nature of const/invariant. It certainly handles 1,2,3,4. 5 is fulfilled subject to my interpretation. They key issue is separating what is constant from the access mode associated with pointers, references and other views. The old "invariant" just means a view of constant data. You know the data is constant and are therefore able to make use of that in optimizations and other cases. Separating those two aspects makes everything fall out simple and consistent: == "Constness" The keyword const would mean "constant" and the meaning is the established one that the compiler may rely on. Constant refers to the actual data (binary representation). Constant variables may not be changed after initialization. = Plain old data A constant (non-manifest versions): const int a = 5; const int b = runtimeFunction(); // Ok const int c = rand(); // Ok The constness of those are a part of their type, so typeof(a) == const(int). A struct with constant members becomes non-assignable (but copyable): struct S { const int a; int b; } The const member has to be initialized at struct initialization. A a = S(1,2); // Ok A b = a; // Ok a = b; // Error: assignment to a constant a.b = b.b; // Ok const S c = S(1,2); // Ok c.b = b.b; // Error = Pointers/Arrays A pointer and array slice to/of constant data: const(int) *a; const(int) a[]; A constant pointer to an int: int x; const int y; const int* a = &x; // Ok *x = 5; // Ok a++; // Error: modifying a constant const int* b = &y; // Error: incompatible types *b = 5; // Ok const(int) *c = &y; c++; // Ok (*c)++; // Error: modifying a constant const const(int) *d = &y; // A constant pointer to a constant int d++; // Error: modifying a constant = Function arguments void foo(ref const(int) x) { x = 5; // Error: modifying a constant } The constness becomes part of the type and const(int)* is not convertible to int*, nor vice versa. Apart from classes, that I will return to later, that is about all there is to say about const. == Access modes: Read only views While const above refers to the modifiability of the actual data, the read-only part refers to the access attributes of a reference. I will use the keyword "in" to mean read-only below, but please substitute with your favorite keyword. (Such as "read", "readonly", "protected" "view", etc) int x; const int y; in int * a = &x; // Ok *a = 5; // Error: No write access in int * b = &y; // Ok *b = 5; // Error: No write access in const(int) * c = &x; // Error: x is not constant in const(int) * d = &y; // Ok typeof(&x) == int * typeof(&y) == in const(int) * so "in const(int) *" is implicitly convertible to "in int *", but not the other way around. Note that the read-only access modifier is implicit in pointers to constant data. Applying the read-only property to a type means all members of the type are read-only: Struct S { int *a; int b; } in S s; s.b = 5; // the read-only part doesn't refer to the actual data, // just the access through references s.a = &x; // Ok; *s.a = 5; // Error: No write access though S An array slice behaves identical to the struct S above. in int[] t; t = &x[0..1]; // Ok t[0] = 5; // Error: No write access though S There is a wish to make the read-only property transitive, which means that applying the read-only property to a type means that all types referred to by the type also gets the read-only property: int *m = &x; // Ok in int **b = &m; // Ok **b = 5; // Error, since typeof(*b) == in int *m Everything is nice and consistent so far. The remaining parts are A) member functions and B) classes. == Member functions. Member functions (methods) are called though a reference. If that reference only has read-only access, only such member functions are allowed to be called. No changes here. Transitivity of the read-only propert will have to be handled manually. Something like: struct Array(T) { T[] arr; accessof!(this) T get()(int i) { return arr[i]; } static if (!is(T == const)) { void set(int i, ref T v) { arr[i] = v; } } } Array!(int); Array!(int *); Array!(const int); // <- This is the "invariant" case == Classes Since classes don't have a value type, it is not possible to define constant classes. I have two views on this. You could come up with a syntax that makes it possible to declare a type that is a reference to a constant class, but it seems to me that most classes that are meant to be constant have to be designed specifically for this purpose, so I propose making the constant a part of the class declaration: const class String { this(char[] data) {...} ... } For classes that support both a modifiable and a constant mode, and the constant mode is important enough to let the compiler know about, one could define: const class ConstString : MutableString { // any non-read-only method of the superclass // is blocked ... } Classes are special beasts that have other was to do access control (a read only view interface for instance). To end, I'd be very interested in hearing what the issues with this design are and what unspoken design requirements this fails to fulfill. -- Oskar
Dec 09 2007
prev sibling parent Robert Fraser <fraserofthenight gmail.com> writes:
Gregor Richards wrote:
 Not a single person on this board (and I mean NO ONE) has a grasp over 
 everything that one can reasonably expect const to do. What we need to 
 do is construct a complete list of features that the const system ought 
 to have, so that any const proposal can be checked against the "good 
 clean const fun" checklist. Instead, what we have is suggestion after 
 suggestion, each with good points but each with fundamental flaws. We're 
 never going to get anywhere like this because nobody knows what everyone 
 needs.
 
 Disclaimer: It is of course impossible to make a list that makes 
 everyone happy. C'est la vie.
 
  - Gregor Richards

Okay, I'll throw my hat into the ring. The most paramount requirement of const for me is _ignorability_. That is, if I don't want to use const or think about const, or even understand const, that should be mostly possible.
Dec 07 2007