www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Clarifying 'const' terminology

reply "Derek Parnell" <derek psych.ward> writes:
I'm not from a C++/C#/Java background, so please excuse my lack of  
understanding about the meaning that is being applied to the term 'const'  
in these recent discussions.

To me, there seems to be two things being talked about.

(a) Data, which once initialized, is not to be modified for the run-time  
life of the application.

(b) Data, which once passed to some function, is not to be modified for  
the run-time life of that function.

Walter's proposed refinement of the 'in' keyword does nothing for type  
(a), and only limited support for type (b), in that it protects data from  
the called function but not from functions that that subsequently calls.  
It is only protection for one level deep. And the only data protected is  
class objects and not other reference types.

Is there any other types (or subtypes) of 'const' meanings being discussed  
or considered?

For example, are we distinguishing between compile-time protection and  
run-time protection?

My requirements for 'const' are almost covered by Walter's new proposal.  
I'm a quite concerned that if I tell Foo() that it can't change something,  
that Foo() can still tell Bar() to disregard my request and tell Bar()  
that it's okay to change it anyway.

I think that apart from array references, type (a) const can be acheived  
through using private members and public properties. I'm not sure how we  
can fully implement (a) with current D semantics.

-- 
Derek Parnell
Melbourne, Australia
Jul 07 2006
next sibling parent reply kris <foo bar.com> writes:
Good idea ~ I'll have a go:

Derek Parnell wrote:
 I'm not from a C++/C#/Java background, so please excuse my lack of  
 understanding about the meaning that is being applied to the term 
 'const'  in these recent discussions.
 
 To me, there seems to be two things being talked about.
 
 (a) Data, which once initialized, is not to be modified for the 
 run-time  life of the application.

There are the traditional 'constant' read-only data types, assigned at the point of declaration (e.g. char[]s = "foo";). It used to be that these were located into a distinct area of memory from read/write program variables and so on. This was done (partly) so that the read-only aspect could be trapped at runtime by the executing device. If you try to modify a D string constant on linux, you'll get a runtime error (Win32 D executables let you happily modify such things), so linux is applying read-only attributes to the segment where this constant data lives. However, the distinction is mostly limited to micro-controllers and other devices with limited RAM, but plenty of ROM -- such readonly constants are traditionally stored in ROM. There's a variation on this called "final", where the constant-value is actually determined at runtime. That is, you get one opportunity to assign a value to a final data type (such as a string) and that's it. Such a compiler will attach compile-time errors to additional assignments.
 (b) Data, which once passed to some function, is not to be modified for  
 the run-time life of that function.

This is the realm of where the discussion has been, vis-a-vis mutable and/or immutable attributes. Tis' a shame 'const' is such an overloaded term
 Walter's proposed refinement of the 'in' keyword does nothing for type  
 (a), and only limited support for type (b), in that it protects data 
 from  the called function but not from functions that that subsequently 
 calls.  It is only protection for one level deep. And the only data 
 protected is  class objects and not other reference types.
 
 Is there any other types (or subtypes) of 'const' meanings being 
 discussed  or considered?

Other than retaining the immutable attribute throughout a given call chain, the other primary subtype (I suppose) is the return value of a function or method.
 For example, are we distinguishing between compile-time protection and  
 run-time protection?

For the mutable/immutable aspect, I believe we're talking purely about the compile time aspect. To sum up the whole discussion, it's really about enhancing the contractual obligation between a caller and callee. For example: As it stands, a callee says "I accept a string as an argument" and the compiler traps those cases, at compile time, where a caller does not provide a string: generates a compile-time error. The mutable attribute enhances this so the callee can say "I need a mutable string, because I will modify it", or "I'm happy with just an immutable string since I use it for read-only purposes". A caller is then obligated to fulfill the (tighter) contract, in a manner similar to how it is currently obliged to provide just a string. The benefits of doing so are numerous, and would probably dilute the value of establishing terminology; so we can probably leave it at that for now?
 My requirements for 'const' are almost covered by Walter's new 
 proposal.  I'm a quite concerned that if I tell Foo() that it can't 
 change something,  that Foo() can still tell Bar() to disregard my 
 request and tell Bar()  that it's okay to change it anyway.

Yes, that is a notable weakness. Using an aggregate (struct or class) instead would give you the /propogation/ aspect required. This is in contrast to Walter's proposal, but requires the use of aggregates rather than, say, an array. BTW: this whole discussion is basically about array types, since others can happily be passed by value anyway. The one problem with using aggregates in this manner is related to return values. For example, you can make a String struct or class and control what each method does to the encapsulated content. At some point, though, the content will likely need exposing. Perhaps via a toString() method or via some other means. Simply duplicating the content at this point is a contentious issue, so some means of tagging the return value as 'immutable', and having that usage enforced, would seem to be necessary.
 I think that apart from array references, type (a) const can be 
 acheived  through using private members and public properties. I'm not 
 sure how we  can fully implement (a) with current D semantics.

Did you mean "... fully implement (b) with current D semantics" instead? As I understand things, it is array references that are at stake here. I don't think anything else is?
Jul 07 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
kris wrote:
 Good idea ~ I'll have a go:
 
 Derek Parnell wrote:
 
 I'm not from a C++/C#/Java background, so please excuse my lack of  
 understanding about the meaning that is being applied to the term 
 'const'  in these recent discussions.


I am from a C++/Java background, yet I still don't fully understand const! The only thing I understand is that Java doesn't need it because it's higher-level than D, doesn't allow pointer manipulation, and has builtin immutable String class. I still don't understand why D needs it, or why do some people think so.
 <snip>
 My requirements for 'const' are almost covered by Walter's new 
 proposal.  I'm a quite concerned that if I tell Foo() that it can't 
 change something,  that Foo() can still tell Bar() to disregard my 
 request and tell Bar()  that it's okay to change it anyway.

Yes, that is a notable weakness. Using an aggregate (struct or class) instead would give you the /propogation/ aspect required. This is in contrast to Walter's proposal, but requires the use of aggregates rather than, say, an array. BTW: this whole discussion is basically about array types, since others can happily be passed by value anyway.

Then how about introducing a new type: read-only array reference. (The idea is inspired by Java's immutable string class) It would be a distinct type, but built into the language core. It has a different declaration syntax from regular arrays. It cannot be casted to anything at all, absolutly no pointer manipulation is allowed either. The content of the array cannot be modified (further explanation below). The reference itself *can* be modified to refer to another array, but it would still be a read-only reference. Any type of regular array reference (dynamic/static/associative) can be converted to a read-only array reference. For example, the syntax could be: int[$] x; //declare x as a readonly reference to an array of "int"s. using the $ might not be the best thing, but please bare with me .. that's not the main point. From now on, I'm gonna assume there's a nice syntax that's consistent with the rest of the D language. To ensure that the content of the array cannot be modified, some measures must be taken regarding what happens when you read an element from the array. Let's agree first on some terminology: Contained Type: if <code> T[$] x; </code> declares a read-only array reference to an array of T's, then T is the contained type. Now, in theory, the contained type can either be - a native type (int, float, byte ... enums .. etc) - a struct - a class (reference) - an array or a pointer. When an element is read from the array, what should we do? - if the contained type is a native type or an enum, then a copy of the element is returned. - if the contained type is a struct, then a copy is returned. That's simple .. but what if the contained type is a class or an array? Well, if it's a class, then it's a little bit complicated. I don't even know if we /need/ any kind of guarantees with an array of objects, but anyway! Let's assume that we do need this guarantee, and let's take a step back. The compiler shouldn't allow the contained type of a read-only array reference to be a class; instead, it should only allow it to be an interface that's derived from a generic (empty) interface called IReadOnly. This measure will not allow the compiler to always ensure that objects contained in such a way cannot be modified, however, it gives the author of the class a guarantee that if he subclasses IReadOnly the right way, then his objects won't be modifiable. Example: ------------------ interface IImmutableCircle : IReadOnly { int radius(); } class Circle : IImmutableCircle { private int mradius; public: int radius() { returm mradius; } void radius( int r ) { mradius = r; } } .... Circle[$] arr; // error, no class allowed as the contained type for a read-only reference IImutableCircle[$] arr; //ok, since IImmutableCircle derives from IReadOnly --------------------------- Of course the coder can mess up his code and add methods in IImmutableCircle that allow the object to be modified, but the important thing is that that's his own reponsibility; no user of his code can mess this up. If there's a loop-hole in this approach, then disregard it. I'm starting to think that the whole issue of protecting objects is unneeded. A similar approach can be taken if the contained type is an array. Either prevent that and require it to be a read-only array reference, or allow it because preventing it is too complicated or just un-needed. So, what do you think about this proposal? Is it practical? Does it solve most of the const issues? Does it even make sense, or is it just stupid all-together? I was gonna post this as a new topic in the main D ng, but I thought it might have been proposed before, so I present it here instead.
 
 The one problem with using aggregates in this manner is related to 
 return values. For example, you can make a String struct or class and 
 control what each method does to the encapsulated content. At some 
 point, though, the content will likely need exposing. Perhaps via a 
 toString() method or via some other means. Simply duplicating the 
 content at this point is a contentious issue, so some means of tagging 
 the return value as 'immutable', and having that usage enforced, would 
 seem to be necessary.

I think the above proposal should covers most of that. The only thing left is adding a toReadOnlyString() to the Object class, or something like that. A Java-like immutable string type can be declared with char[$] x; // x is an immutable string! Well, it's not really immutable, but the reference is read-only, so the string cannot be modified thru that reference.
Jul 07 2006
next sibling parent reply kris <foo bar.com> writes:
Hasan Aljudy wrote:
[snip]
 Then how about introducing a new type: read-only array reference.
 (The idea is inspired by Java's immutable string class)
 
 It would be a distinct type, but built into the language core.
 It has a different declaration syntax from regular arrays.
 It cannot be casted to anything at all, absolutly no pointer 
 manipulation is allowed either.
 The content of the array cannot be modified (further explanation below).
 The reference itself *can* be modified to refer to another array, but it 
 would still be a read-only reference.
 Any type of regular array reference (dynamic/static/associative) can be 
 converted to a read-only array reference.

Having a true set of readonly array[] types would certainly resolve all such issues that I've personally encountered with D, although some might balk at having another set of TypeInfo? On the other hand, that may be wholly preferable to implementing a type-modifier instead? It is also fully backward compatible ;) [snip other good stuff] Really don't think any special-cases are required here ~ if a readonly array, of any type, is used as an lValue in any manner, it is a compile-time error. Simple, neat, easy to understand. What's missing? * interfacing with extern(C) functions via pointers? * pointers in general, within D? I suspect the above could be handled in a minimalist manner? e.g. I suspect we could probably get by without readonly-pointers in D. I use pointers quite a bit as function arguments, but I can't think of a case where an array wouldn't suffice instead (in order to get immutable arguments). In other words, to simplify things as much as possible we should consider the minimal subset with the most mileage ~ the best bang for the buck * what else?
Jul 07 2006
parent reply Sean Kelly <sean f4.ca> writes:
kris wrote:
 Hasan Aljudy wrote:
 [snip]
 Then how about introducing a new type: read-only array reference.
 (The idea is inspired by Java's immutable string class)

 It would be a distinct type, but built into the language core.
 It has a different declaration syntax from regular arrays.
 It cannot be casted to anything at all, absolutly no pointer 
 manipulation is allowed either.
 The content of the array cannot be modified (further explanation below).
 The reference itself *can* be modified to refer to another array, but 
 it would still be a read-only reference.
 Any type of regular array reference (dynamic/static/associative) can 
 be converted to a read-only array reference.

Having a true set of readonly array[] types would certainly resolve all such issues that I've personally encountered with D, although some might balk at having another set of TypeInfo? On the other hand, that may be wholly preferable to implementing a type-modifier instead? It is also fully backward compatible ;) [snip other good stuff] Really don't think any special-cases are required here ~ if a readonly array, of any type, is used as an lValue in any manner, it is a compile-time error. Simple, neat, easy to understand.

A ReadOnly array would still need to access the contents of a standard array for this to be useful, so it couldn't be completely excluded from evaluation as an lvalue--initializations would be exempt. Sean
Jul 08 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Sean Kelly wrote:
 kris wrote:
 
 Hasan Aljudy wrote:
 [snip]

 Then how about introducing a new type: read-only array reference.
 (The idea is inspired by Java's immutable string class)

 It would be a distinct type, but built into the language core.
 It has a different declaration syntax from regular arrays.
 It cannot be casted to anything at all, absolutly no pointer 
 manipulation is allowed either.
 The content of the array cannot be modified (further explanation below).
 The reference itself *can* be modified to refer to another array, but 
 it would still be a read-only reference.
 Any type of regular array reference (dynamic/static/associative) can 
 be converted to a read-only array reference.

Having a true set of readonly array[] types would certainly resolve all such issues that I've personally encountered with D, although some might balk at having another set of TypeInfo? On the other hand, that may be wholly preferable to implementing a type-modifier instead? It is also fully backward compatible ;) [snip other good stuff] Really don't think any special-cases are required here ~ if a readonly array, of any type, is used as an lValue in any manner, it is a compile-time error. Simple, neat, easy to understand.

A ReadOnly array would still need to access the contents of a standard array for this to be useful, so it couldn't be completely excluded from evaluation as an lvalue--initializations would be exempt. Sean

It's actually an array "reference" .. you can make it refer to (point to) any normal array, i.e. you can change what it refers to. You just can't use that reference to change the properties or contents of the array. You can use it to read the contents of the array it refers to. Think of it as an interface with read-only methods and no write methods.
Jul 08 2006
prev sibling next sibling parent BCS <BCS_member pathlink.com> writes:
In article <e8n6v9$2csb$1 digitaldaemon.com>, Hasan Aljudy says...

I am from a C++/Java background, yet I still don't fully understand const!
The only thing I understand is that Java doesn't need it because it's 
higher-level than D, doesn't allow pointer manipulation, and has builtin 
immutable String class.

I still don't understand why D needs it, or why do some people think so.

Then how about introducing a new type: read-only array reference.
(The idea is inspired by Java's immutable string class)

It would be a distinct type, but built into the language core.
It has a different declaration syntax from regular arrays.
It cannot be casted to anything at all, absolutly no pointer 
manipulation is allowed either.
The content of the array cannot be modified (further explanation below).
The reference itself *can* be modified to refer to another array, but it 
would still be a read-only reference.
Any type of regular array reference (dynamic/static/associative) can be 
converted to a read-only array reference.

Except for the object stuff and, for the most part, the different declaration syntax, this is just about the same as the const type I have been wanting. A syntax that says "this array can't be changed" would cover about %95+ of what I want. Extending this to direct access to public members of classes and structs would put it up to %99+.
Jul 07 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Hasan Aljudy wrote:
 
 
 kris wrote:
 Good idea ~ I'll have a go:

 Derek Parnell wrote:

 I'm not from a C++/C#/Java background, so please excuse my lack of  
 understanding about the meaning that is being applied to the term 
 'const'  in these recent discussions.


I am from a C++/Java background, yet I still don't fully understand const! The only thing I understand is that Java doesn't need it because it's higher-level than D, doesn't allow pointer manipulation, and has builtin immutable String class. I still don't understand why D needs it, or why do some people think so.
 <snip>
 My requirements for 'const' are almost covered by Walter's new 
 proposal.  I'm a quite concerned that if I tell Foo() that it can't 
 change something,  that Foo() can still tell Bar() to disregard my 
 request and tell Bar()  that it's okay to change it anyway.

Yes, that is a notable weakness. Using an aggregate (struct or class) instead would give you the /propogation/ aspect required. This is in contrast to Walter's proposal, but requires the use of aggregates rather than, say, an array. BTW: this whole discussion is basically about array types, since others can happily be passed by value anyway.

Then how about introducing a new type: read-only array reference. (The idea is inspired by Java's immutable string class) It would be a distinct type, but built into the language core. It has a different declaration syntax from regular arrays. It cannot be casted to anything at all, absolutly no pointer manipulation is allowed either. The content of the array cannot be modified (further explanation below). The reference itself *can* be modified to refer to another array, but it would still be a read-only reference. Any type of regular array reference (dynamic/static/associative) can be converted to a read-only array reference. For example, the syntax could be: int[$] x; //declare x as a readonly reference to an array of "int"s. using the $ might not be the best thing, but please bare with me .. that's not the main point. From now on, I'm gonna assume there's a nice syntax that's consistent with the rest of the D language. To ensure that the content of the array cannot be modified, some measures must be taken regarding what happens when you read an element from the array. Let's agree first on some terminology: Contained Type: if <code> T[$] x; </code> declares a read-only array reference to an array of T's, then T is the contained type. Now, in theory, the contained type can either be - a native type (int, float, byte ... enums .. etc) - a struct - a class (reference) - an array or a pointer. When an element is read from the array, what should we do? - if the contained type is a native type or an enum, then a copy of the element is returned. - if the contained type is a struct, then a copy is returned. That's simple .. but what if the contained type is a class or an array? Well, if it's a class, then it's a little bit complicated. I don't even know if we /need/ any kind of guarantees with an array of objects, but anyway! Let's assume that we do need this guarantee, and let's take a step back. The compiler shouldn't allow the contained type of a read-only array reference to be a class; instead, it should only allow it to be an interface that's derived from a generic (empty) interface called IReadOnly. This measure will not allow the compiler to always ensure that objects contained in such a way cannot be modified, however, it gives the author of the class a guarantee that if he subclasses IReadOnly the right way, then his objects won't be modifiable. Example: ------------------ interface IImmutableCircle : IReadOnly { int radius(); } class Circle : IImmutableCircle { private int mradius; public: int radius() { returm mradius; } void radius( int r ) { mradius = r; } } ..... Circle[$] arr; // error, no class allowed as the contained type for a read-only reference IImutableCircle[$] arr; //ok, since IImmutableCircle derives from IReadOnly --------------------------- Of course the coder can mess up his code and add methods in IImmutableCircle that allow the object to be modified, but the important thing is that that's his own reponsibility; no user of his code can mess this up. If there's a loop-hole in this approach, then disregard it. I'm starting to think that the whole issue of protecting objects is unneeded. A similar approach can be taken if the contained type is an array. Either prevent that and require it to be a read-only array reference, or allow it because preventing it is too complicated or just un-needed. So, what do you think about this proposal? Is it practical? Does it solve most of the const issues? Does it even make sense, or is it just stupid all-together? I was gonna post this as a new topic in the main D ng, but I thought it might have been proposed before, so I present it here instead.
 The one problem with using aggregates in this manner is related to 
 return values. For example, you can make a String struct or class and 
 control what each method does to the encapsulated content. At some 
 point, though, the content will likely need exposing. Perhaps via a 
 toString() method or via some other means. Simply duplicating the 
 content at this point is a contentious issue, so some means of tagging 
 the return value as 'immutable', and having that usage enforced, would 
 seem to be necessary.

I think the above proposal should covers most of that. The only thing left is adding a toReadOnlyString() to the Object class, or something like that. A Java-like immutable string type can be declared with char[$] x; // x is an immutable string! Well, it's not really immutable, but the reference is read-only, so the string cannot be modified thru that reference.

Indeed, if I understood your proposal correctly, I think it is unpractical, if not down-right senseless. :p Why? Ok, first, what do we want exactly? We want a mechanism that allows us to specify a readonly contract for a variable, that is, declare a variable (or function parameter) that should be a "read-only view" (using Andrei Alexandrescu's term) of another data/object. Your proposal allows us to do that, but one has to encapsulate/declare the var, inside a "constant array of the type of that var"? Why not just declare it as a "constant var of it's respective type"? For example, if I want to declare a function that receives a readonly Object, I have to: ... func(Object[$] obj) { obj[0].doStuff(); int b = obj[0].num; Have to access obj as an array, even though it is only one Object? Why not just: ... func(readonly Object obj) { obj.doStuff(); int b = obj.num; Similarly, on the return type: Object[$] func(...) { obj2 = new Object(); ... // **** Want to return a readonly obj2: **** // Have to allocate an array and encapsulate obj2 inside it? : auto objAR = new Object[$]; // how do I even specify the length?? objAR[0] = obj2; return objAR; } instead of just: readonly Object func(...) { obj2 = new Object(); ... // **** Want to return a readonly obj2: **** return obj2; } Plus, your proposal is omissive in many important aspects. For example, how about the transitive property? If I have: int **[$] cptr; can I change *(cptr[0]) or **(cptr[0])? Similarly for a struct: struct Fuu { int[] iar; } Fuu[$] cfuu; can I change (cfuu[0]).iar[ix] ? (where ix is some index) And your method for determining how one can use a readonly object seems way cumbersome(have to define an interface), and likely less efficient(have to use interfaces). I mean, having to define an interface for each class, with the methods that are allowed in the readonly object?? Compare this to C++ (and Javari), where you just add a keyword to the methods that can be called by a readonly(const) instance: In C++ it is: void aMethod(...) const { ... } In Javari it is: void aMethod(...) readonly { ... } (Note: basically, what is being done above is specifying the constness of the 'this' implicit parameter) I must quote what I've said in the OP: Implementing a mechanism such as this is actually quite complex (in terms of design itself) because of several special cases which need more language constructs. It's not just adding the "immutable" keyword as some people seem to think. To know what I'm talking about exactly one should read this quite informative paper: http://pag.csail.mit.edu/pubs/ref-immutability-oopsla2005-abstract.html I haven't read it all yet, but I plan to do so soon, since everyone is talking about const again. And I would say reading it should likely be mandatory for anyone who wants to venture thinking and posting how the const system should work. It describes the issues one faces when implementing such a system, and the reference immutability system described there is perhaps a good starting point for a system for D BTW, Javari is the Java modification described in that paper, which has reference immutability added to the Java language. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 08 2006
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Bruno Medeiros wrote:
 Hasan Aljudy wrote:

 So, what do you think about this proposal?
 Is it practical? Does it solve most of the const issues?
 Does it even make sense, or is it just stupid all-together?


 
 
 Indeed, if I understood your proposal correctly, I think it is 
 unpractical, if not down-right senseless. :p
 
 Why?
 Ok, first, what do we want exactly? We want a mechanism that allows us 
 to specify a readonly contract for a variable, that is, declare a 
 variable (or function parameter) that should be a "read-only view" 
 (using Andrei Alexandrescu's term) of another data/object.

No, if you check my proposal, it was a reply to kris's statement: "this whole discussion is basically about array types, since others can happily be passed by value anyway." and that is also my understanding. structs, enums, and native types can hapily be passed by value - no const feature needed. classes can provide interfaces for read-only access, or a class can be made immutable - no const feature needed. The only thing left is arrays. Look at Java, it has one of the best/richest/most robust libraries I've ever seen, and it doesn't have any const feature per se. The only thing it has that D doesn't is immutable strings. So, according to my understanding of the issue, if D would have read-only array references, the const issue would mostly be solved.
 
 Your proposal allows us to do that, but one has to encapsulate/declare 
 the var, inside a "constant array of the type of that var"? Why not just 
 declare it as a "constant var of it's respective type"? For example, if 
 I want to declare a function that receives a readonly Object, I have to:
 
   ... func(Object[$] obj) {
      obj[0].doStuff();
      int b = obj[0].num;

No, if you do this, according to my proposal, then you cannot modify the list of "Object" references inside "obj", but there's no guarantee on the actual instances that are referred to by these references.
 Have to access obj as an array, even though it is only one Object?
 Why not just:
 
   ... func(readonly Object obj) {
      obj.doStuff();
      int b = obj.num;
 
 Similarly, on the return type:
 

 
   readonly Object func(...) {
     obj2 = new Object();
     ...
 
     // **** Want to return a readonly obj2: ****
     return obj2;
   }
 

I am under the impression that C++ like constness is out of the question <g>
 
 Plus, your proposal is omissive in many important aspects. For example, 
 how about the transitive property? If I have:
   int **[$] cptr;
 can I change *(cptr[0]) or **(cptr[0])? Similarly for a struct:
   struct Fuu { int[] iar; }
   Fuu[$] cfuu;
 can I change (cfuu[0]).iar[ix] ?  (where ix is some index)

you can do what you want with the array reference .. when ever you access an element of the array you're getting a copy of that element. if that element is a pointer, you're getting a copy of the pointer. if you don't want this to happen, don't frickin use pointers when you don't want others to manipulate your array!! <snip>
 
 BTW, Javari is the Java modification described in that paper, which has 
 reference immutability added to the Java language.
 

I need to ask .. what did javari *really* add to java? Is there something that's impossible with java but possible with javari? . . . no? I thought so.
Jul 08 2006
next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Hasan Aljudy wrote:
 
 
 Bruno Medeiros wrote:
 Hasan Aljudy wrote:

 So, what do you think about this proposal?
 Is it practical? Does it solve most of the const issues?
 Does it even make sense, or is it just stupid all-together?


 Indeed, if I understood your proposal correctly, I think it is 
 unpractical, if not down-right senseless. :p

 Why?
 Ok, first, what do we want exactly? We want a mechanism that allows us 
 to specify a readonly contract for a variable, that is, declare a 
 variable (or function parameter) that should be a "read-only view" 
 (using Andrei Alexandrescu's term) of another data/object.

No, if you check my proposal, it was a reply to kris's statement: "this whole discussion is basically about array types, since others can happily be passed by value anyway." and that is also my understanding.

If that is your premise,then that system would work for it, but I don't agree with such a premise. I have to say I didn't understand Kris's context in the surroundings statements, like the "Using an aggregate (struct or class) instead would give you the /propogation/ aspect required. This is in contrast to Walter's proposal, but requires the use of aggregates rather than, say, an array.", but in any case it seems to me an immutability mechanism is needed for any kind of reference type, like Objects too, not just arrays. I mean, if I have a function that has an Object parameter and I want to specify and enforce that the Object should not be changed in the function, what am I supposed to do?
 BTW, Javari is the Java modification described in that paper, which 
 has reference immutability added to the Java language.

I need to ask .. what did javari *really* add to java? Is there something that's impossible with java but possible with javari? .. .. .. no? I thought so.

Impossible? No, not in the strict sense. But "better", "more powerful", "more expressive", etc., then yes, in my opinion it does. Do refrain from using the word "possible" in comparisons between languages. You'll be asking for the typical reply that any Turing complete language can do the same things as any other such language, so we might as well be using Assembler. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Bruno Medeiros wrote:
 Hasan Aljudy wrote:
 
 Bruno Medeiros wrote:

 Hasan Aljudy wrote:

<snip proposal>
 So, what do you think about this proposal?
 Is it practical? Does it solve most of the const issues?
 Does it even make sense, or is it just stupid all-together?


 Indeed, if I understood your proposal correctly, I think it is 
 unpractical, if not down-right senseless. :p

 Why?
 Ok, first, what do we want exactly? We want a mechanism that allows 
 us to specify a readonly contract for a variable, that is, declare a 
 variable (or function parameter) that should be a "read-only view" 
 (using Andrei Alexandrescu's term) of another data/object.

No, if you check my proposal, it was a reply to kris's statement: "this whole discussion is basically about array types, since others can happily be passed by value anyway." and that is also my understanding.

If that is your premise,then that system would work for it, but I don't agree with such a premise. I have to say I didn't understand Kris's context in the surroundings statements, like the "Using an aggregate (struct or class) instead would give you the /propogation/ aspect required. This is in contrast to Walter's proposal, but requires the use of aggregates rather than, say, an array.", but in any case it seems to me an immutability mechanism is needed for any kind of reference type, like Objects too, not just arrays. I mean, if I have a function that has an Object parameter and I want to specify and enforce that the Object should not be changed in the function, what am I supposed to do?
 BTW, Javari is the Java modification described in that paper, which 
 has reference immutability added to the Java language.

I need to ask .. what did javari *really* add to java? Is there something that's impossible with java but possible with javari? .. .. .. no? I thought so.

Impossible? No, not in the strict sense. But "better", "more powerful", "more expressive", etc., then yes, in my opinion it does. Do refrain from using the word "possible" in comparisons between languages. You'll be asking for the typical reply that any Turing complete language can do the same things as any other such language, so we might as well be using Assembler.

What I meant is .. Java already has one of the most powerfull libraries I've seen (not that I've seen much anyways, mind you). I was wondering what does javari has to offer that java doesn't? or let me say, what does it add? When we talk about 'possibilities' in this context, we're not talking about algorithms. I mean for instance, in the C langauge: void x( int * p ); It's impossible for the function x to detect whether p points to an array or just a single int. and if it's array, it's impossible to know the size of the array.
Jul 09 2006
prev sibling parent BCS <BCS_member pathlink.com> writes:
In article <e8pa25$1ud6$1 digitaldaemon.com>, Hasan Aljudy says...
Bruno Medeiros wrote:

 
 Plus, your proposal is omissive in many important aspects. For example, 
 how about the transitive property? If I have:


you can do what you want with the array reference ..
when ever you access an element of the array you're getting a copy of 
that element.
if that element is a pointer, you're getting a copy of the pointer.
if you don't want this to happen, don't frickin use pointers when you 
don't want others to manipulate your array!!

Ok, then how do you pass the common type of char[][] to a function? Const more than one level deep is necessary in my mind. I'd recommend that a const reference can't refer to a non const reference. It has the advantage of being simple and easy to understand. Unless this has been shown to not work, I think that it would be informative to try it for a while. *Question for Walter*: How hard would it be to implement several const models, in parallel (DMD ver 0.162a, 0.163b,...) This would let people try them and see how well they work. [...]
I need to ask .. what did javari *really* add to java?
Is there something that's impossible with java but possible with javari?

no?
I thought so.

Const doesn't make anything new possible, it makes things impossible, and that's the point.
Jul 09 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
 I'm not from a C++/C#/Java background, so please excuse my lack of 
 understanding about the meaning that is being applied to the term 
 'const' in these recent discussions.
 

I think many times people talked a bit vaguely with their meaning of const.
 To me, there seems to be two things being talked about.
 
 (a) Data, which once initialized, is not to be modified for the run-time 
 life of the application.
 
 (b) Data, which once passed to some function, is not to be modified for 
 the run-time life of that function.
 
 Walter's proposed refinement of the 'in' keyword does nothing for type 
 (a), and only limited support for type (b), in that it protects data 
 from the called function but not from functions that that subsequently 
 calls. It is only protection for one level deep. And the only data 
 protected is class objects and not other reference types.
 
 Is there any other types (or subtypes) of 'const' meanings being 
 discussed or considered?
 
 For example, are we distinguishing between compile-time protection and 
 run-time protection?
 

'const', in a general sense, is a mechanism to specify whether a variable/data/object can or can not modified, and enforce that contract (at compile time). 'const' is usually in the sense of (b), that is, some parts of code may modify the data, while others can only read it (thus it is used for ownership management). That's the case for C++. Enforcing the contract means you cannot assign a const variable to a non-const one, or similarly, pass a const variable to a function that expects a non-const argument. The only way to subvert this is with a cast (which should be the only way to subvert anything). There are some variations in const semantics. In C++, const is a type-modifier, meaning that const can be applied to each type element, and not the "variable as whole". Best to give an example. In C++ you can have: const int * iptr = ...; int const * iptr = ...; const int const * iptr = ...; each with different meanings: const int * iptr = ...; // cannot modify the pointed int, can modify the pointer int const * iptr = ...; // can modify the pointed int, cannot modify the pointer (the pointer is const) const int const * iptr = ...; // Cannot modify the pointed int, nor cannot modify the pointer In this usual meaning (C++), there are no guarantees that the data will not actually change (by someone else for example) or that it is a compile constant. (That is why I say the use of this notion of const is for ownership management). In D, 'const' is not a type modifier but what Walter calls a "storage modifier" (or storage attribute), but I think "variable modifier" is perhaps a better term. D's const is applied not to each of many possible type elements, but to the whole variable, like private or other protection attributes (and as such there can be only one const per declaration). D's const also has two different meanings (a bad thing IMO), and they're both different from C++'s: * const var declaration with an initializer: -> the value of the variable is a compile time constant. The variable has no storage, it becomes an alias for it's initializer literal. (and has such one can't take the address of it) * const var declaration without an initializer: -> the var can be initialized in constructors only, and on all other places it's value is read-only. The variable has normal storage. This is what is (much more properly) called 'final' in other languages. There are some more possible variations. There can be a const that has the same meaning as C++'s (you cannot change the var), but which is a variable modifier instead of a type modifier. But in this case there is a prominent issue of whether the read-only/immutability property is transitive or not. For example (calling this behavior 'readonly'): readonly int **ptr; Can one change *ptr and **ptr ? Or just ptr? And there are quite some more issues to consider when implementing a 'const' mechanism such as this one. (see below)
 My requirements for 'const' are almost covered by Walter's new proposal. 
 I'm a quite concerned that if I tell Foo() that it can't change 
 something, that Foo() can still tell Bar() to disregard my request and 
 tell Bar() that it's okay to change it anyway.
 
 I think that apart from array references, type (a) const can be acheived 
 through using private members and public properties. I'm not sure how we 
 can fully implement (a) with current D semantics.
 
 --Derek Parnell
 Melbourne, Australia

I'm assuming that in that that last "(a)" you meant "(b)". Implementing a mechanism such as this is actually quite complex (in terms of design itself) because of several special cases which need more language constructs. It's not just adding the "immutable" keyword as some people seem to think. To know what I'm talking about exactly one should read this quite informative paper: http://pag.csail.mit.edu/pubs/ref-immutability-oopsla2005-abstract.html I haven't read it all yet, but I plan to do so soon, since everyone is talking about const again. And I would say reading it should likely be mandatory for anyone who wants to venture thinking and posting how the const system should work. It describes the issues one faces when implementing such a system, and the reference immutability system described there is perhaps a good starting point for a system for D. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 08 2006
next sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bruno Medeiros wrote:
 Derek Parnell wrote:
 
 I'm not from a C++/C#/Java background, so please excuse my lack of 
 understanding about the meaning that is being applied to the term 
 'const' in these recent discussions.

I think many times people talked a bit vaguely with their meaning of const.
 To me, there seems to be two things being talked about.

 (a) Data, which once initialized, is not to be modified for the 
 run-time life of the application.

 (b) Data, which once passed to some function, is not to be modified 
 for the run-time life of that function.

 Walter's proposed refinement of the 'in' keyword does nothing for type 
 (a), and only limited support for type (b), in that it protects data 
 from the called function but not from functions that that subsequently 
 calls. It is only protection for one level deep. And the only data 
 protected is class objects and not other reference types.

 Is there any other types (or subtypes) of 'const' meanings being 
 discussed or considered?

 For example, are we distinguishing between compile-time protection and 
 run-time protection?

'const', in a general sense, is a mechanism to specify whether a variable/data/object can or can not modified, and enforce that contract (at compile time). 'const' is usually in the sense of (b), that is, some parts of code may modify the data, while others can only read it (thus it is used for ownership management). That's the case for C++. Enforcing the contract means you cannot assign a const variable to a non-const one, or similarly, pass a const variable to a function that expects a non-const argument. The only way to subvert this is with a cast (which should be the only way to subvert anything). There are some variations in const semantics. In C++, const is a type-modifier, meaning that const can be applied to each type element, and not the "variable as whole". Best to give an example. In C++ you can have: const int * iptr = ...; int const * iptr = ...; const int const * iptr = ...; each with different meanings: const int * iptr = ...; // cannot modify the pointed int, can modify the pointer int const * iptr = ...; // can modify the pointed int, cannot modify the pointer (the pointer is const) const int const * iptr = ...; // Cannot modify the pointed int, nor cannot modify the pointer

There's another place you can put 'const' in C++: class A { void bar(int i); int foo() const; }; This "const" ensures that the member function A::foo does not modify the instance of A that you are calling it on. (If the function does do so, it is a compile error.) This is an issue when you are dealing with const instances of A: const A a; a.bar(12); // ERROR! a is const, A::bar is not a.foo(); // Okay I actually view this as necessary if we get a way to declare an instance as immutable in D. (Honestly, I have few issues with C++ const, though this "const-by-default for class instances" idea has merit, too.)
 In this usual meaning (C++), there are no guarantees that the data will 
 not actually change (by someone else for example) or that it is a 
 compile constant. (That is why I say the use of this notion of const is 
 for ownership management).
 
 In D, 'const' is not a type modifier but what Walter calls a "storage 
 modifier" (or storage attribute), but I think "variable modifier" is 
 perhaps a better term. D's const is applied not to each of many possible 
 type elements, but to the whole variable, like private or other 
 protection attributes (and as such there can be only one const per 
 declaration). D's const also has two different meanings (a bad thing 
 IMO), and they're both different from C++'s:
 
 * const var declaration with an initializer:
 -> the value of the variable is a compile time constant. The variable 
 has no storage, it becomes an alias for it's initializer literal. (and 
 has such one can't take the address of it)
 
 * const var declaration without an initializer:
 -> the var can be initialized in constructors only, and on all other 
 places it's value is read-only. The variable has normal storage. This is 
 what is (much more properly) called 'final' in other languages.
 
 There are some more possible variations. There can be a const that has 
 the same meaning as C++'s (you cannot change the var), but which is a 
 variable modifier instead of a type modifier. But in this case there is 
 a prominent issue of whether the read-only/immutability property is 
 transitive or not. For example (calling this behavior 'readonly'):
   readonly int **ptr;
 Can one change *ptr and **ptr ? Or just ptr?
 
 And there are quite some more issues to consider when implementing a 
 'const' mechanism such as this one. (see below)
 
 My requirements for 'const' are almost covered by Walter's new 
 proposal. I'm a quite concerned that if I tell Foo() that it can't 
 change something, that Foo() can still tell Bar() to disregard my 
 request and tell Bar() that it's okay to change it anyway.

 I think that apart from array references, type (a) const can be 
 acheived through using private members and public properties. I'm not 
 sure how we can fully implement (a) with current D semantics.

 --Derek Parnell
 Melbourne, Australia

I'm assuming that in that that last "(a)" you meant "(b)". Implementing a mechanism such as this is actually quite complex (in terms of design itself) because of several special cases which need more language constructs. It's not just adding the "immutable" keyword as some people seem to think. To know what I'm talking about exactly one should read this quite informative paper: http://pag.csail.mit.edu/pubs/ref-immutability-oopsla2005-abstract.html I haven't read it all yet, but I plan to do so soon, since everyone is talking about const again. And I would say reading it should likely be mandatory for anyone who wants to venture thinking and posting how the const system should work. It describes the issues one faces when implementing such a system, and the reference immutability system described there is perhaps a good starting point for a system for D.

-- Kirk McDonald Pyd: Wrapping Python with D http://dsource.org/projects/pyd/wiki
Jul 08 2006
parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 06:05:11 +1000, Kirk McDonald  
<kirklin.mcdonald gmail.com> wrote:



 There's another place you can put 'const' in C++:

 class A {
      void bar(int i);
      int foo() const;
 };

 This "const" ensures that the member function A::foo does not modify the  
 instance of A that you are calling it on. (If the function does do so,  
 it is a compile error.) This is an issue when you are dealing with const  
 instances of A:

 const A a;

 a.bar(12); // ERROR! a is const, A::bar is not
 a.foo();   // Okay

 I actually view this as necessary if we get a way to declare an instance  
 as immutable in D. (Honestly, I have few issues with C++ const, though  
 this "const-by-default for class instances" idea has merit, too.)

I can see why this would be a good thing in C++, because the declaration of A::foo() and the definition of A::foo() is not necessarily in the same source file or even written by the same person. This style of 'const' is a way to document a design decision in source code and thus have the compiler enforce the design. However, in D they are one and the same thing - a class member must be declared and defined at the same time. So if the design decision is that A.foo() is not allowed to change any of the data members in an A object, there is no way to get the compiler to know about that design decision. So maybe it would be a useful debugging aid. -- Derek Parnell Melbourne, Australia
Jul 08 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Derek Parnell wrote:
 On Sun, 09 Jul 2006 06:05:11 +1000, Kirk McDonald 
 <kirklin.mcdonald gmail.com> wrote:
 
 
 
 There's another place you can put 'const' in C++:

 class A {
      void bar(int i);
      int foo() const;
 };

 This "const" ensures that the member function A::foo does not modify 
 the instance of A that you are calling it on. (If the function does do 
 so, it is a compile error.) This is an issue when you are dealing with 
 const instances of A:

 const A a;

 a.bar(12); // ERROR! a is const, A::bar is not
 a.foo();   // Okay

 I actually view this as necessary if we get a way to declare an 
 instance as immutable in D. (Honestly, I have few issues with C++ 
 const, though this "const-by-default for class instances" idea has 
 merit, too.)

I can see why this would be a good thing in C++, because the declaration of A::foo() and the definition of A::foo() is not necessarily in the same source file or even written by the same person. This style of 'const' is a way to document a design decision in source code and thus have the compiler enforce the design. However, in D they are one and the same thing - a class member must be declared and defined at the same time. So if the design decision is that A.foo() is not allowed to change any of the data members in an A object, there is no way to get the compiler to know about that design decision. So maybe it would be a useful debugging aid. --Derek Parnell Melbourne, Australia

"However, in D they are one and the same thing - a class member must be declared and defined at the same time." Not entirely correct, remember d header files? What happens in D, is that if there is a definition, then there must also be declaration (they're the same actually). But there can be just a definition: class Foo { void func(); } This means that in D, just as C++, there is no way for the compiler to know in all cases whether the func changes or not the object instance. Thus, it is necessary for the user to specify it. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Bruno Medeiros wrote:
<snip>
 
 
 "However, in D they are one and the same thing - a class member must be 
 declared and defined at the same time."
 Not entirely correct, remember d header files? What happens in D, is 
 that if there is a definition, then there must also be declaration 
 (they're the same actually). But there can be just a definition:
 
   class Foo {
     void func();
   }
 
 This means that in D, just as C++, there is no way for the compiler to 
 know in all cases whether the func changes or not the object instance. 
 Thus, it is necessary for the user to specify it.
 

However, practically speaking, in D (unlike C++) the interface is probably always derived from the actual implementation.
Jul 09 2006
prev sibling parent BCS <BCS pathlink.com> writes:
Bruno Medeiros wrote:
 Derek Parnell wrote:
 
 On Sun, 09 Jul 2006 06:05:11 +1000, Kirk McDonald 
 <kirklin.mcdonald gmail.com> wrote:



 There's another place you can put 'const' in C++:

 class A {
      void bar(int i);
      int foo() const;
 };

 This "const" ensures that the member function A::foo does not modify 
 the instance of A that you are calling it on. (If the function does 
 do so, it is a compile error.) This is an issue when you are dealing 
 with const instances of A:

 const A a;

 a.bar(12); // ERROR! a is const, A::bar is not
 a.foo();   // Okay

 I actually view this as necessary if we get a way to declare an 
 instance as immutable in D. (Honestly, I have few issues with C++ 
 const, though this "const-by-default for class instances" idea has 
 merit, too.)

I can see why this would be a good thing in C++, because the declaration of A::foo() and the definition of A::foo() is not necessarily in the same source file or even written by the same person. This style of 'const' is a way to document a design decision in source code and thus have the compiler enforce the design. However, in D they are one and the same thing - a class member must be declared and defined at the same time. So if the design decision is that A.foo() is not allowed to change any of the data members in an A object, there is no way to get the compiler to know about that design decision. So maybe it would be a useful debugging aid. --Derek Parnell Melbourne, Australia

"However, in D they are one and the same thing - a class member must be declared and defined at the same time." Not entirely correct, remember d header files? What happens in D, is that if there is a definition, then there must also be declaration (they're the same actually). But there can be just a definition: class Foo { void func(); } This means that in D, just as C++, there is no way for the compiler to know in all cases whether the func changes or not the object instance. Thus, it is necessary for the user to specify it.

Another reason that the compiler can't tell is derived classes. Additionally, letting the compiler check for const methods would requirer the checking algorithm to be specified by D. Some algorithms will say "go" in the example class is const, some will say it isn't. class foo { char[] format; this(char[] f){ format = f.dup; } char[] go(int i) { int j; char[] f = format; // f points to member data foreach(int k, char c; f) if("%" = c) { j = k; break; } if("%" == f[j]) { // copy f (might not be noticed) f = f[0..j+1]~toString(i)~f[j+1..$]; f[j] = " "; // assign to f } return f; } }
Jul 10 2006
prev sibling next sibling parent reply Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
Bruno Medeiros wrote:
 There are some variations in const semantics. In C++, const is a
 type-modifier, meaning that const can be applied to each type element,
 and not the "variable as whole". Best to give an example. In C++ you can
 have:
   const int * iptr = ...;
   int const * iptr = ...;
   const int const * iptr = ...;
 each with different meanings:
 
   const int * iptr = ...;
   // cannot modify the pointed int, can modify the pointer
 
   int const * iptr = ...;
   // can modify the pointed int, cannot modify the pointer (the pointer
 is const)
 
   const int const * iptr = ...;
   // Cannot modify the pointed int, nor cannot modify the pointer
 

Actually, the former two are equivalent. To clarify (equivalent types are paired on one line): const int, int const const int *, int const * const int * const, int const * const int * const There's only one way to write that last one: a constant pointer to a non-constant integer. This is why I always write "const" second when writing C(++): it'd be inconsistent with the way const pointers are written out to do otherwise. Plus, they can be read right-to-left more easily. ("const int * const" reads as "constant pointer to an integer --- no, wait, a constant integer" to me <g>)
Jul 08 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Deewiant wrote:
 Bruno Medeiros wrote:
 There are some variations in const semantics. In C++, const is a
 type-modifier, meaning that const can be applied to each type element,
 and not the "variable as whole". Best to give an example. In C++ you can
 have:
   const int * iptr = ...;
   int const * iptr = ...;
   const int const * iptr = ...;
 each with different meanings:

   const int * iptr = ...;
   // cannot modify the pointed int, can modify the pointer

   int const * iptr = ...;
   // can modify the pointed int, cannot modify the pointer (the pointer
 is const)

   const int const * iptr = ...;
   // Cannot modify the pointed int, nor cannot modify the pointer

Actually, the former two are equivalent. To clarify (equivalent types are paired on one line): const int, int const const int *, int const * const int * const, int const * const int * const

Oops, that's right, thanks for correcting me. I should have tested it, it's not the first time it got const declarations mixed up, damn C++ ... :p -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 08 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Bruno Medeiros wrote:
 Derek Parnell wrote:
 I'm not from a C++/C#/Java background, so please excuse my lack of 
 understanding about the meaning that is being applied to the term 
 'const' in these recent discussions.

I think many times people talked a bit vaguely with their meaning of const.
 To me, there seems to be two things being talked about.

 (a) Data, which once initialized, is not to be modified for the 
 run-time life of the application.

 (b) Data, which once passed to some function, is not to be modified 
 for the run-time life of that function.

 Walter's proposed refinement of the 'in' keyword does nothing for type 
 (a), and only limited support for type (b), in that it protects data 
 from the called function but not from functions that that subsequently 
 calls. It is only protection for one level deep. And the only data 
 protected is class objects and not other reference types.

 Is there any other types (or subtypes) of 'const' meanings being 
 discussed or considered?

 For example, are we distinguishing between compile-time protection and 
 run-time protection?

'const', in a general sense, is a mechanism to specify whether a variable/data/object can or can not modified, and enforce that contract (at compile time). 'const' is usually in the sense of (b), that is, some parts of code may modify the data, while others can only read it (thus it is used for ownership management). That's the case for C++. Enforcing the contract means you cannot assign a const variable to a non-const one, or similarly, pass a const variable to a function that expects a non-const argument. The only way to subvert this is with a cast (which should be the only way to subvert anything).

In the realm of compiler optimization techniques, there's another issue as well: can the compiler assume that, because it is evaluating a const reference, that the underlying data will not change while that reference is in use. This is the truly sticky part, and is I think a large reason why Walter hasn't settled on anything yet. For example, consider "const by default": void readWrite( inout T val ) {} void readOnly( in T val ) {} T val; readWrite( inout val ); ... readOnly( val ); In the above, because a mutable reference to val is obtained before readOnly is called, can the compiler assume that the contents of val will not change while readOnly is being evaluated? Can it ever make that assumption for the entire life of the program after readWrite is called?
 There are some variations in const semantics. In C++, const is a 
 type-modifier, meaning that const can be applied to each type element, 
 and not the "variable as whole". Best to give an example. In C++ you can 
 have:
   const int * iptr = ...;
   int const * iptr = ...;

These two are actually identical. Though things can get a bit tricky if 'int' is replaced by a typedef involving a reference type, which is why the latter form tends to be preferred these days--it is unambiguous, unlike the former form.
   const int const * iptr = ...;
 each with different meanings:

I believe this is the same as the above, you merely applied the const to int twice. What you probably meant for these three was: const int * iptr = ...; // mutable ptr to const int int const * iptr = ...; // same as previous line int * const iptr = ...; // const ptr to mutable int const int * const iptr = ...; // const ptr to const int int const * const iptr = ...; // same as previous line To return to the typedef issue for a moment, if you do: typedef char* pchar; template<class T> void func( const T val ) {} pchar val = "hello"; func( val ); then it's not entirely clear whether the val in func is a const pointer to mutable data or vice-versa. Thus the preferred method is: template<class T> void func( T const val ) {} Where it's obvious that the 'const' will apply to the pointer if one exists. Sean
Jul 08 2006
next sibling parent reply "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 08:03:52 +1000, Sean Kelly <sean f4.ca> wrote:



 In the realm of compiler optimization techniques, there's another issue  
 as well: can the compiler assume that, because it is evaluating a const  
 reference, that the underlying data will not change while that reference  
 is in use.

Just to clarify, are you saying that while a function that was passed a 'const' reference is running, can the compiler assume that so other concurrently running function will change the passed data?
 This is the truly sticky part, and is I think a large reason why Walter  
 hasn't settled on anything yet.  For example, consider "const by  
 default":

      void readWrite( inout T val ) {}
      void readOnly( in T val ) {}

      T val;

      readWrite( inout val );
      ...
      readOnly( val );

 In the above, because a mutable reference to val is obtained before  
 readOnly is called, can the compiler assume that the contents of val  
 will not change while readOnly is being evaluated?  Can it ever make  
 that assumption for the entire life of the program after readWrite is  
 called?

If functions are not being run concurrently, I think it can. Because while the code in readOnly() is executing, how can code in other functions execute if they are not called somehow by readOnly itself? Or am I missing something (again <g>). -- Derek Parnell Melbourne, Australia
Jul 08 2006
parent Sean Kelly <sean f4.ca> writes:
Derek Parnell wrote:
 On Sun, 09 Jul 2006 08:03:52 +1000, Sean Kelly <sean f4.ca> wrote:
 
 
 
 In the realm of compiler optimization techniques, there's another 
 issue as well: can the compiler assume that, because it is evaluating 
 a const reference, that the underlying data will not change while that 
 reference is in use.

Just to clarify, are you saying that while a function that was passed a 'const' reference is running, can the compiler assume that so other concurrently running function will change the passed data?

Yes, be it in another thread or merely called through an opaque function pointer inside the const-qualified code. But at some point I think the user simply has to promise not to be evil so the compiler can go on with its job. I'm just not sure exactly where the line should be drawn. Sean
Jul 08 2006
prev sibling next sibling parent Dave <Dave_member pathlink.com> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 Derek Parnell wrote:
 I'm not from a C++/C#/Java background, so please excuse my lack of 
 understanding about the meaning that is being applied to the term 
 'const' in these recent discussions.

I think many times people talked a bit vaguely with their meaning of const.
 To me, there seems to be two things being talked about.

 (a) Data, which once initialized, is not to be modified for the 
 run-time life of the application.

 (b) Data, which once passed to some function, is not to be modified 
 for the run-time life of that function.

 Walter's proposed refinement of the 'in' keyword does nothing for 
 type (a), and only limited support for type (b), in that it protects 
 data from the called function but not from functions that that 
 subsequently calls. It is only protection for one level deep. And the 
 only data protected is class objects and not other reference types.

 Is there any other types (or subtypes) of 'const' meanings being 
 discussed or considered?

 For example, are we distinguishing between compile-time protection 
 and run-time protection?

'const', in a general sense, is a mechanism to specify whether a variable/data/object can or can not modified, and enforce that contract (at compile time). 'const' is usually in the sense of (b), that is, some parts of code may modify the data, while others can only read it (thus it is used for ownership management). That's the case for C++. Enforcing the contract means you cannot assign a const variable to a non-const one, or similarly, pass a const variable to a function that expects a non-const argument. The only way to subvert this is with a cast (which should be the only way to subvert anything).

In the realm of compiler optimization techniques, there's another issue as well: can the compiler assume that, because it is evaluating a const reference, that the underlying data will not change while that reference is in use. This is the truly sticky part, and is I think a large reason why Walter hasn't settled on anything yet. For example, consider "const by default": void readWrite( inout T val ) {} void readOnly( in T val ) {} T val; readWrite( inout val ); ... readOnly( val ); In the above, because a mutable reference to val is obtained before readOnly is called, can the compiler assume that the contents of val will not change while readOnly is being evaluated? Can it ever make that assumption for the entire life of the program after readWrite is called?

For either const by default or most of Walter's 'in' proposal (for byref function parameters), there may be a solution at the bottom of: digitalmars.D/39757 It does rely on a non-release-build runtime check (just like array bounds checking) so it isn't perfect, but at least it's consistent with other language and reference implementation features, and as such I think the optimization techniques you mention could be safely applied for 'const' parameters. That would truly be cool IMHO. I think this would make const-by-default or 'in' parameters a lot easier to debug and safer for passing byref args. around in multi-threaded apps. too. Even for non-release builds the assert(x !is y) would be substantially faster than bounds checking in simple loops so the overhead isn't that terrible.
 There are some variations in const semantics. In C++, const is a 
 type-modifier, meaning that const can be applied to each type element, 
 and not the "variable as whole". Best to give an example. In C++ you 
 can have:
   const int * iptr = ...;
   int const * iptr = ...;

These two are actually identical. Though things can get a bit tricky if 'int' is replaced by a typedef involving a reference type, which is why the latter form tends to be preferred these days--it is unambiguous, unlike the former form.
   const int const * iptr = ...;
 each with different meanings:

I believe this is the same as the above, you merely applied the const to int twice. What you probably meant for these three was: const int * iptr = ...; // mutable ptr to const int int const * iptr = ...; // same as previous line int * const iptr = ...; // const ptr to mutable int const int * const iptr = ...; // const ptr to const int int const * const iptr = ...; // same as previous line To return to the typedef issue for a moment, if you do: typedef char* pchar; template<class T> void func( const T val ) {} pchar val = "hello"; func( val ); then it's not entirely clear whether the val in func is a const pointer to mutable data or vice-versa. Thus the preferred method is: template<class T> void func( T const val ) {} Where it's obvious that the 'const' will apply to the pointer if one exists. Sean

Jul 08 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly wrote:
 Bruno Medeiros wrote:
 Derek Parnell wrote:
 I'm not from a C++/C#/Java background, so please excuse my lack of 
 understanding about the meaning that is being applied to the term 
 'const' in these recent discussions.

I think many times people talked a bit vaguely with their meaning of const.
 To me, there seems to be two things being talked about.

 (a) Data, which once initialized, is not to be modified for the 
 run-time life of the application.

 (b) Data, which once passed to some function, is not to be modified 
 for the run-time life of that function.

 Walter's proposed refinement of the 'in' keyword does nothing for 
 type (a), and only limited support for type (b), in that it protects 
 data from the called function but not from functions that that 
 subsequently calls. It is only protection for one level deep. And the 
 only data protected is class objects and not other reference types.

 Is there any other types (or subtypes) of 'const' meanings being 
 discussed or considered?

 For example, are we distinguishing between compile-time protection 
 and run-time protection?

'const', in a general sense, is a mechanism to specify whether a variable/data/object can or can not modified, and enforce that contract (at compile time). 'const' is usually in the sense of (b), that is, some parts of code may modify the data, while others can only read it (thus it is used for ownership management). That's the case for C++. Enforcing the contract means you cannot assign a const variable to a non-const one, or similarly, pass a const variable to a function that expects a non-const argument. The only way to subvert this is with a cast (which should be the only way to subvert anything).

In the realm of compiler optimization techniques, there's another issue as well: can the compiler assume that, because it is evaluating a const reference, that the underlying data will not change while that reference is in use. This is the truly sticky part, and is I think a large reason why Walter hasn't settled on anything yet. For example, consider "const by default": void readWrite( inout T val ) {} void readOnly( in T val ) {} T val; readWrite( inout val ); ... readOnly( val ); In the above, because a mutable reference to val is obtained before readOnly is called, can the compiler assume that the contents of val will not change while readOnly is being evaluated? Can it ever make that assumption for the entire life of the program after readWrite is called?

Yes, but one has to realize that that is a different thing from the readonly view type of immutability, which is used for ownership management. You can't have 'const' or any other keyword mean both things. C++'s 'const' has only the meaning of a readonly view type of contract. It does not mean the data cannot change (although in case of a value type, it indeed can't). I recall the discussion between Walter and Alexei where Walter complained that C++'s const was not very useful because it didn't guarantee data was non-changing. Alexei took a while to make Walter understand that that was not the purpose and usefulness of the kind of const/language-construct that he was considering important (which was the readonly view construct).
 There are some variations in const semantics. In C++, const is a 
 type-modifier, meaning that const can be applied to each type element, 
 and not the "variable as whole". Best to give an example. In C++ you 
 can have:
   const int * iptr = ...;
   int const * iptr = ...;

These two are actually identical. Though things can get a bit tricky if 'int' is replaced by a typedef involving a reference type, which is why the latter form tends to be preferred these days--it is unambiguous, unlike the former form.
   const int const * iptr = ...;
 each with different meanings:

I believe this is the same as the above, you merely applied the const to int twice. What you probably meant for these three was: const int * iptr = ...; // mutable ptr to const int int const * iptr = ...; // same as previous line int * const iptr = ...; // const ptr to mutable int const int * const iptr = ...; // const ptr to const int int const * const iptr = ...; // same as previous line

Yes, Deewiant had pointed that out already. ;)
 To return to the typedef issue for a moment, if you do:
 
     typedef char* pchar;
 
     template<class T> void func( const T val ) {}
 
     pchar val = "hello";
 
     func( val );
 
 then it's not entirely clear whether the val in func is a const pointer 
 to mutable data or vice-versa.  Thus the preferred method is:
 
     template<class T> void func( T const val ) {}
 
 Where it's obvious that the 'const' will apply to the pointer if one 
 exists.
 
 
 Sean

Another of C++'s subtle trickinesses... I'll keep that in mind, if I have to deal with it in the future. -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jul 09 2006
prev sibling parent "Derek Parnell" <derek psych.ward> writes:
On Sun, 09 Jul 2006 05:45:50 +1000, Bruno Medeiros  
<brunodomedeirosATgmail SPAM.com> wrote:

 Derek Parnell wrote:

 To me, there seems to be two things being talked about.
  (a) Data, which once initialized, is not to be modified for the  
 run-time life of the application.
  (b) Data, which once passed to some function, is not to be modified  
 for the run-time life of that function.


 I'm not sure how we can fully implement (a) with current D semantics.


 I'm assuming that in that that last "(a)" you meant "(b)".

No actually. I really did mean (a). So far as I understand it, all the discussions of 'const' still fall into either of these two categories. I know that compile-time constants are in category (a). Both styles of constants, as implemented in D, are of type (a) because once inititialized their value is not allowed to be changed ever by anything. Another type of 'const' that falls into (a) is the 'const' returned value. I see that as being that some function creates data and asks that no one change it while the data exists. This type of (a) is the one that I can't see how to implement in current D. The (b) category is easy to implement in D currently. Just pass a copy of the data to a function, then the function, and other functions that it may call, can play with the copy until it's heart's content with no harm done (apart from side effects <g>). But this method is can obviously be a performance hit, plus it doesn't help track down mistakes in the called functions - that is when the called functions accidently attempt to change data it knows it shouldn't. So in summary, I believe that D does not completely implement either of the two 'const' categories at all. And everyone, including Walter, seems to agree on that point. What there seems to be some disagreement on is whether or not D is obliged to implement 'const'. -- Derek Parnell Melbourne, Australia
Jul 08 2006