www.digitalmars.com         C & C++   DMDScript  

D - c++ style const concept

reply Chris Sokol <chris echosproject.org> writes:
Does D support it at all?
Aug 07 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Chris Sokol" <chris echosproject.org> wrote in message
news:bgv1t6$1ijj$1 digitaldaemon.com...
 Does D support it at all?

D supports const as a storage class, but not as a type modifier.
Aug 07 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
What's the rationale again?

"Walter" <walter digitalmars.com> wrote in message
news:bgvd22$1sna$1 digitaldaemon.com...
 "Chris Sokol" <chris echosproject.org> wrote in message
 news:bgv1t6$1ijj$1 digitaldaemon.com...
 Does D support it at all?

D supports const as a storage class, but not as a type modifier.

Aug 07 2003
parent reply "Walter" <walter digitalmars.com> writes:
1) Too complicated (look at all the wierd rules and perterbations it causes
with template specialization and overloading).
2) Too confusing.
3) Insufficient utility.
4) Optimizers can't reliably use the info anyway.
5) Ugly.

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bgvdh2$1t4n$1 digitaldaemon.com...
 What's the rationale again?

 "Walter" <walter digitalmars.com> wrote in message
 news:bgvd22$1sna$1 digitaldaemon.com...
 "Chris Sokol" <chris echosproject.org> wrote in message
 news:bgv1t6$1ijj$1 digitaldaemon.com...
 Does D support it at all?

D supports const as a storage class, but not as a type modifier.


Aug 08 2003
next sibling parent reply Farmer <itsFarmer. freenet.de> writes:
"Walter" <walter digitalmars.com> wrote in 
news:bh1f3a$psi$1 digitaldaemon.com:

 4) Optimizers can't reliably use the info anyway.

Optimizing *library writers* need that info to write optimized code that is *robust*. Quotting from Phobos string.d: /************** Constants ****************/ const char[16] hexdigits = "0123456789ABCDEF"; /*********************************************** * Convert to char[]. */ char[] toString(uint u) { char[uint.size * 3] buffer; int ndigits; char c; char[] result; ndigits = 0; if (u < 10) // Avoid storage allocation for simple stuff result = digits[u .. u + 1]; else { while (u) { c = (u % 10) + '0'; u /= 10; ndigits++; buffer[buffer.length - ndigits] = c; } result = new char[ndigits]; result[] = buffer[buffer.length - ndigits .. buffer.length]; } return result; } Looks like nice code ? But the code isn't robust as this example proves: int main(char args[][]) { char[] digit=toString(1); assert(digit[0] == '1'); digit[0]='9'; char[] digit2=toString(1); assert(digit2[0] == '1'); // assertion fails ! return 0; }
Aug 09 2003
next sibling parent "Walter" <walter digitalmars.com> writes:
"Farmer" <itsFarmer. freenet.de> wrote in message
news:Xns93D2F2BCBD361itsFarmer 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:bh1f3a$psi$1 digitaldaemon.com:

 4) Optimizers can't reliably use the info anyway.

Optimizing *library writers* need that info to write optimized code that

 *robust*.

 Quotting from Phobos string.d:

 /************** Constants ****************/
 const char[16] hexdigits = "0123456789ABCDEF";

 /***********************************************
 * Convert to char[].
 */
 char[] toString(uint u)
 {
    char[uint.size * 3] buffer;
    int ndigits;
    char c;
    char[] result;

    ndigits = 0;
    if (u < 10)
       // Avoid storage allocation for simple stuff
       result = digits[u .. u + 1];
    else
    {
       while (u)
       {
          c = (u % 10) + '0';
          u /= 10;
          ndigits++;
          buffer[buffer.length - ndigits] = c;
       }
       result = new char[ndigits];
       result[] = buffer[buffer.length - ndigits .. buffer.length];
    }
    return result;
 }


 Looks like nice code ?

 But the code isn't robust as this example proves:
 int main(char args[][])
 {
    char[] digit=toString(1);
    assert(digit[0] == '1');
    digit[0]='9';

    char[] digit2=toString(1);
    assert(digit2[0] == '1');   // assertion fails !
    return 0;
 }

The assumption that Phobos uses throughout is copy-on-write. That means that unless you're the generator of a string, if you modify it, make a copy first. This avoids the problems the code snippet shows, while retaining max performance.
Aug 09 2003
prev sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Farmer" <itsFarmer. freenet.de> a écrit dans le message de
news:Xns93D2F2BCBD361itsFarmer 63.105.9.61...
 "Walter" <walter digitalmars.com> wrote in
 news:bh1f3a$psi$1 digitaldaemon.com:

 4) Optimizers can't reliably use the info anyway.

Optimizing *library writers* need that info to write optimized code that

 *robust*.

 Quotting from Phobos string.d:

I think that for "standard" libraries, the more information is available on a type, the more we can write code that could be optimized... This is particulary interesting for template where we could select the appropriate algorithm depending on some attributes or modifier... Ideally, it should be possible to extract modifier information and any other usefull information when we want to... but when we do not want we should be able to do 1 algorithm that works for all (supported) cases. It may be interesting to be able to distinguate concept (an object that appears const) and reality (an object in read-only memory) when needed
Aug 12 2003
prev sibling next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 1) Too complicated (look at all the wierd rules and perterbations it

 with template specialization and overloading).

I cannot contest that it's complicated, as you're the expert on compiler-waltering.
 2) Too confusing.

Disagree. Seems perfectly clear to me.
 3) Insufficient utility.

You couldn't be more wrong
 4) Optimizers can't reliably use the info anyway.

Have no knowledge here
 5) Ugly.

Not meaningful. Most things in SE are ugly until you get used to them like, say, D's templates ... ;)
Aug 09 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bh3rhp$u1$1 digitaldaemon.com...
 1) Too complicated (look at all the wierd rules and perterbations it

 with template specialization and overloading).

compiler-waltering.
 2) Too confusing.


'Seems' is the operative word here <g>. Const has a seductive simplicity that's a mirage. Check out all the weird and wild ways it influences function overloading, argument deduction, partial specialization, and partial ordering.
 3) Insufficient utility.


Show me where it's useful. I finally stripped it out of my code, as it never found a bug after 15 years using it thinking it might help find a bug.
 4) Optimizers can't reliably use the info anyway.


I have a lot of practice trying to make use of const info in the optimizer. There isn't any. The optimizer always winds up having to assume that the data pointed to by a pointer to const changes anyway. Then there's 'mutable', const casts, etc. Const doesn't guarantee that the underlying data doesn't change, so it is useless for optimization.
 5) Ugly.


 say, D's templates ... ;)

I see all the 'const' qualifiers over and over as obfuscation. API declarations look a lot cleaner and straightforward without them.
Aug 09 2003
parent reply Bill Cox <bill viasic.com> writes:
3) Insufficient utility.

You couldn't be more wrong

Show me where it's useful. I finally stripped it out of my code, as it never found a bug after 15 years using it thinking it might help find a bug.

Hi, Mathew. I would be very interested in hearing about the utility of const. I'm not disputing your assertion, but I haven't had the same experience. We also dropped the use of const from our coding style at work, and I can't remember spending 1 minute tracking down a bug that const would have prevented. Perhaps there was a better way, but I feel like we were force to drop the use of 'const' pointers. The problem is that it was too much for our guys to type on 90% of all object handles passed to functions. I had a hell of a time enforcing it. Overall, it seemed to hurt our programmers ability to work together. Perhaps a 'variable' keyword or some such to declare what parameters get modified would have worked out. To me, it seems Walter has chosen good middle ground by supporting the use of 'const' only as a storage class modifier. Bill
Aug 11 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Walter has done so by sacrificing the language's ability to pass around
constants except by copying them.  Think about big arrays of constants, or
constant structures.

To safely pass a constant by reference you have to be able to ensure that
nobody will alter the original version.

Once you start passing pointers around to various functions it becomes
impossible to statically ascertain whether a given call will violate the
constness of the data you are essentially passing in by reference.  Thus to
be certain, the compiler is forced to make a copy of all const data before
passing it by reference.

One way around this is make the static checking more robust, by say
decorating the function signature with information about how the function
modifies its reference parameters, and information about all functions this
function might call with those parameters so that checking can pursue all
possible routes by which the function might alter the parameter.  Only once
this has been done can the compiler safely pass in the original const data
instead of a copy.

I believe the same problem exists for determining register saving when using
so-called fastcall calling conventions.  If you can determine a called
function will not clobber a register, you are safe to assume you can leave
values there over the call, and much saving and restoring can be prevented
or at least delayed to the point where it must be done due to the limited
number of registers.

With const, however, a protocol for parameter passing is not so easy.  You
surely want to avoid copying data as much as possible, but occasionally it
might be worth copying the data if that would be easier than burdening an
entire call with restrictions.

I certainly wouldn't want a language to permit anyone to modify data I
declare as a constant.  Yet I want to be able to pass those constants to
functions by reference without them being copied, so long as the function is
safe for passing const data to.  And if I try to pass a constant to a
function that will potentially modify the contents, I wish to be warned at
compile time instead of having silent copies generated that I can't keep
track of.

The compiler is probably much better at keeping tabs on what functions do or
do not alter their parameters than I am.  Therefore it should be assigned
the task of adorning parameters with constness, as well as making sure const
data only gets passed by reference to those sorts of parameters.  An error
would mention the const data passed, as well as point out at least one bit
of offending code which prevents such a call, directly or indirectly,
preferrably with some sort of route taken thru the code by which said
problem could happen.  That would be enough info for a programmer that
wished the function to actually be const-safe to eradicate the offending
writes.

Presto, D language syntax and grammar doesn't change, just the semantics
slightly altered with a validity check inserted into the compiler, which it
should enforce to the best of its ability.

Problem solved, everybody happy.  ;)  Except poor Walter, who would have to
implement it.

Does anyone else think const in C++ is a poor attempt at letting the user
decorate info that a sophisticated enough compiler could be able to figure
out on its own?  Somewhat akin to the "register" keyword, which "aids" the
compiler by disallowing any possibility of aliasing the value stored?  It's
also something the compiler can figure out for you, something that modern
compilers do.  They even do a pretty good job at it, from what I understand,
though C++'s laxity with pointers allows hideous data flow spaghetti that
even the best compilers cannot sort out.

Whatever it takes to get the compiler to make good code.  I often must sound
like I'm asking for alot.

Another nice thing about keeping track of constness is that a pointer to
constant data need never be freed, but that affects D very little since it's
built around garbage collection which gives you this anyway, for free.  ;)

Yet another nice thing about passing constants is that it serves as an
indicator to the optimizer that it might be able to generate a custom
version of the function tailored with the constant completely inlined.  It's
something people would want to do (identity matrix, anybody?) and I would
expect the compiler to try to take advantage of such a situation.

Sean

"Bill Cox" <bill viasic.com> wrote in message
news:bh85p6$1324$1 digitaldaemon.com...
3) Insufficient utility.

You couldn't be more wrong

Show me where it's useful. I finally stripped it out of my code, as it


 found a bug after 15 years using it thinking it might help find a bug.

Hi, Mathew. I would be very interested in hearing about the utility of const. I'm not disputing your assertion, but I haven't had the same experience. We also dropped the use of const from our coding style at work, and I can't remember spending 1 minute tracking down a bug that const would have prevented. Perhaps there was a better way, but I feel like we were force to drop the use of 'const' pointers. The problem is that it was too much for our guys to type on 90% of all object handles passed to functions. I had a hell of a time enforcing it. Overall, it seemed to hurt our programmers ability to work together. Perhaps a 'variable' keyword or some such to declare what parameters get modified would have worked out. To me, it seems Walter has chosen good middle ground by supporting the use of 'const' only as a storage class modifier. Bill

Aug 12 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
That's a damn site better job than I was revving up for, Bill, so I'll
merely say "hear, hear".

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bha4n0$8q2$1 digitaldaemon.com...
 Walter has done so by sacrificing the language's ability to pass around
 constants except by copying them.  Think about big arrays of constants, or
 constant structures.

 To safely pass a constant by reference you have to be able to ensure that
 nobody will alter the original version.

 Once you start passing pointers around to various functions it becomes
 impossible to statically ascertain whether a given call will violate the
 constness of the data you are essentially passing in by reference.  Thus

 be certain, the compiler is forced to make a copy of all const data before
 passing it by reference.

 One way around this is make the static checking more robust, by say
 decorating the function signature with information about how the function
 modifies its reference parameters, and information about all functions

 function might call with those parameters so that checking can pursue all
 possible routes by which the function might alter the parameter.  Only

 this has been done can the compiler safely pass in the original const data
 instead of a copy.

 I believe the same problem exists for determining register saving when

 so-called fastcall calling conventions.  If you can determine a called
 function will not clobber a register, you are safe to assume you can leave
 values there over the call, and much saving and restoring can be prevented
 or at least delayed to the point where it must be done due to the limited
 number of registers.

 With const, however, a protocol for parameter passing is not so easy.  You
 surely want to avoid copying data as much as possible, but occasionally it
 might be worth copying the data if that would be easier than burdening an
 entire call with restrictions.

 I certainly wouldn't want a language to permit anyone to modify data I
 declare as a constant.  Yet I want to be able to pass those constants to
 functions by reference without them being copied, so long as the function

 safe for passing const data to.  And if I try to pass a constant to a
 function that will potentially modify the contents, I wish to be warned at
 compile time instead of having silent copies generated that I can't keep
 track of.

 The compiler is probably much better at keeping tabs on what functions do

 do not alter their parameters than I am.  Therefore it should be assigned
 the task of adorning parameters with constness, as well as making sure

 data only gets passed by reference to those sorts of parameters.  An error
 would mention the const data passed, as well as point out at least one bit
 of offending code which prevents such a call, directly or indirectly,
 preferrably with some sort of route taken thru the code by which said
 problem could happen.  That would be enough info for a programmer that
 wished the function to actually be const-safe to eradicate the offending
 writes.

 Presto, D language syntax and grammar doesn't change, just the semantics
 slightly altered with a validity check inserted into the compiler, which

 should enforce to the best of its ability.

 Problem solved, everybody happy.  ;)  Except poor Walter, who would have

 implement it.

 Does anyone else think const in C++ is a poor attempt at letting the user
 decorate info that a sophisticated enough compiler could be able to figure
 out on its own?  Somewhat akin to the "register" keyword, which "aids" the
 compiler by disallowing any possibility of aliasing the value stored?

 also something the compiler can figure out for you, something that modern
 compilers do.  They even do a pretty good job at it, from what I

 though C++'s laxity with pointers allows hideous data flow spaghetti that
 even the best compilers cannot sort out.

 Whatever it takes to get the compiler to make good code.  I often must

 like I'm asking for alot.

 Another nice thing about keeping track of constness is that a pointer to
 constant data need never be freed, but that affects D very little since

 built around garbage collection which gives you this anyway, for free.  ;)

 Yet another nice thing about passing constants is that it serves as an
 indicator to the optimizer that it might be able to generate a custom
 version of the function tailored with the constant completely inlined.

 something people would want to do (identity matrix, anybody?) and I would
 expect the compiler to try to take advantage of such a situation.

 Sean

 "Bill Cox" <bill viasic.com> wrote in message
 news:bh85p6$1324$1 digitaldaemon.com...
3) Insufficient utility.

You couldn't be more wrong

Show me where it's useful. I finally stripped it out of my code, as it


 found a bug after 15 years using it thinking it might help find a bug.

Hi, Mathew. I would be very interested in hearing about the utility of const. I'm not disputing your assertion, but I haven't had the same experience. We also dropped the use of const from our coding style at work, and I can't remember spending 1 minute tracking down a bug that const would have prevented. Perhaps there was a better way, but I feel like we were force to drop the use of 'const' pointers. The problem is that it was too much for our guys to type on 90% of all object handles passed to functions. I had a hell of a time enforcing it. Overall, it seemed to hurt our programmers ability to work together. Perhaps a 'variable' keyword or some such to declare what parameters get modified would have worked out. To me, it seems Walter has chosen good middle ground by supporting the use of 'const' only as a storage class modifier. Bill


Aug 12 2003
parent reply Bill Cox <bill viasic.com> writes:
Matthew Wilson wrote:
 That's a damn site better job than I was revving up for, Bill, so I'll
 merely say "hear, hear".

Hi, Matthew and Sean. I very much respect both of your opinions on this. I just have a somewhat different view point.
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 
Walter has done so by sacrificing the language's ability to pass around
constants except by copying them.  Think about big arrays of constants, or
constant structures.

To safely pass a constant by reference you have to be able to ensure that
nobody will alter the original version.

Once you start passing pointers around to various functions it becomes
impossible to statically ascertain whether a given call will violate the
constness of the data you are essentially passing in by reference.  Thus

to
be certain, the compiler is forced to make a copy of all const data before
passing it by reference.


The compiler doesn't make any copies of constant arrays, as demonstraited with the following code and results: const int [] a = [1, 2, 3, 4]; void writeOverConstArray( int [] a) { int i; for(i = 0; i < 4; i++) { a[i] *= a[i]; } } int main(char[][] args) { int i; writeOverConstArray(a); for(i = 0; i < 4; i++) { printf("a[%d] = %d\n", i, a[i]); } return 0; }
 const

a[1] = 4 a[2] = 9 a[3] = 16 The compiler simply doesn't prove that constant data isn't over-written. ...
I certainly wouldn't want a language to permit anyone to modify data I
declare as a constant.


I think this is the heart of the issue. If you didn't feel that way, would you still want D to prove that constant data isn't modified? I'm not questioning the validity of how you feel about it, but I doubt it's based on repeated experience of getting burned by having your constants overwritten. I'd guess you've been using 'const' properly ever since it was introduced in C++, and haven't been in a position to find out how many bugs you've avoided. Again, if Walter wants D to feel like a smooth highway to C++ programmers, including full constant protection might help. Frankly, I've always been annoyed by it, since it makes it harder for our code to interface with other peoples code (our code doesn't use const protection, their code requires it). We all wind up writing lots of casts to use eachother's code.
Does anyone else think const in C++ is a poor attempt at letting the user
decorate info that a sophisticated enough compiler could be able to figure
out on its own?  Somewhat akin to the "register" keyword, which "aids" the
compiler by disallowing any possibility of aliasing the value stored?


Yes. Definately. Why not just have the compiler try to prove that constant data is never modified, rather than having me put 'const' keywords in all my parameter declarations? Is this what you're getting at? If so, I'm for it. It would eliminate all the cast nonsense 'const' creates when we use eachother's code.
 It's
 
also something the compiler can figure out for you, something that modern
compilers do.  They even do a pretty good job at it, from what I

understand,
though C++'s laxity with pointers allows hideous data flow spaghetti that
even the best compilers cannot sort out.

Whatever it takes to get the compiler to make good code.  I often must

sound
like I'm asking for alot.


So do the rest of us.
Another nice thing about keeping track of constness is that a pointer to
constant data need never be freed, but that affects D very little since

it's
built around garbage collection which gives you this anyway, for free.  ;)

Yet another nice thing about passing constants is that it serves as an
indicator to the optimizer that it might be able to generate a custom
version of the function tailored with the constant completely inlined.

It's
something people would want to do (identity matrix, anybody?) and I would
expect the compiler to try to take advantage of such a situation.


I agree. However, Walter's asserted that the compiler doesn't get to do such optimizations. I'm always for making faster code. Bill
Aug 12 2003
next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
The "const" qualifier is conceptually similar to Java's "throws"
statements. Both are designed to make some static guarantees about the
program's behavior.

However, taking care of the "throws" statements causes the programmers
to fallback to the "catch and ignore all exceptions" mode.  Similarly,
when it comes to usage of "const" (in C++) some programmers fall back to
the "ignore const altogether and when I need to interface with software
that actually uses const qualifiers, just cast them away".

This comes as no surprise: Manually taking care of things just
complicates interfaces and makes the programmer bored.

So the main question is, should one make a programming language that
will make programming fun, or one that allows for as strict static
guarantees as possible?

D seems to have taken the first route, and I'm not complaining.

There would be two solutions for ensuring that no const object will
change: one that examines the program text and automatically decorates
the interfaces (or an internal database, or whatever) with the knowledge
like "function x treats arguments y and z as constants", as per Sean's
suggestion. (If I got it right). The problem is how you define the of
library interfaces and how to make the whole thing visible to the
programmer so that he knows what's going on.

Another could relying for run-time guarantees: placing the const data in
a page with only read-only access, and turning hardware exceptions into
D exceptions if possible. This is what C++ does (in addition to static
guarantees of const) and that's my personal preference, too.

-Antti
Aug 12 2003
parent reply "Fabian Giesen" <rygNO SPAMgmx.net> writes:
Antti Sykäri wrote:
 So the main question is, should one make a programming language that
 will make programming fun, or one that allows for as strict static
 guarantees as possible?

The C++ const doesn't make any strict static guarantees, that's why it's worthless for a compilers' optimizer and also why it ultimately is only an annoyance. In C++, not only can anyone cast away constness, there's not even a clear consensus on what actually *is* const. Some go for "no byte is ever changed", some go for "no outside visible state is ever changed". The latter in general makes more sense, but it implies that data members of const classes *can* change (as long as it's invisible to the rest of the world :), which in turn means that neither the compiler nor the programmer can really rely on const meaning "nothing ever changes", especially since both have their subtilities. Even a byte-by-byte const class that never changes can actually change its state if it contains a pointer to some non-const object that changes; and the other way round, a conceptually const object can change its internal storage quite often :) Add to that the several subtilities in C++ regarding const (things like the compiler implicitly converting values to const references if need be, which is useful, but somewhat awkward really) and I can very well understand why a compiler writer wouldn't see much benefit in it.
 Another could relying for run-time guarantees: placing the const data
 in a page with only read-only access, and turning hardware exceptions
 into D exceptions if possible. This is what C++ does (in addition to
 static guarantees of const) and that's my personal preference, too.

This does not work with the conceptual const-ness approach, which limits the usefulness of const quite dramatically. -fg
Aug 14 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
"Fabian Giesen" <rygNO SPAMgmx.net> a écrit dans le message de
news:bhggt3$fiq$1 digitaldaemon.com...
 Antti Sykäri wrote:
 So the main question is, should one make a programming language that
 will make programming fun, or one that allows for as strict static
 guarantees as possible?

The C++ const doesn't make any strict static guarantees, that's why it's worthless for a compilers' optimizer and also why it ultimately is only an annoyance.

So IMO we need a way that allows us to tell the compiler that we want strict guarantees for some data...
 In C++, not only can anyone cast away constness, there's not even a
 clear consensus on what actually *is* const. Some go for "no byte is
 ever changed", some go for "no outside visible state is ever changed".
 The latter in general makes more sense, but it implies that data members
 of const classes *can* change (as long as it's invisible to the rest of
 the world :), which in turn means that neither the compiler nor the
 programmer can really rely on const meaning "nothing ever changes",
 especially since both have their subtilities. Even a byte-by-byte const
 class that never changes can actually change its state if it contains a
 pointer to some non-const object that changes; and the other way round,
 a conceptually const object can change its internal storage quite often :)

There we need a few keyword to denote each interesting cases... We declaring data, we have a few possibilities: - compile-time constants - static constant data (always exists and with proper value) - run-time constant data (const while object exists) - non constant data We passing data as parameter, we have 3 possibilities: - we may want to allows modifications - we don't want visible (state) modification - we don't want any modification We using data, we have 4 possibilities: - the data is not const, we can modifie any way we want - the data is declared const but not physically const, can be modified with a cast - idem but the data may also be modified externally... - the data is physically const, cannot be modified even with a cast (this could include compile-time constant and could help making meta-programming easier by allowing function like syntax for integral types...) IMO in, inout and out should be strict for parameters. That is, it should not be possible to modify in parameters. We could uses "immuable" as a modifier to tell the compiler that it can assumes that the data won't be modified externally or alternatively "volatile" if the compiler should not assumes it (depending on what we prefer as the default - safer or faster) or maybe both. If immuable is supported, they we can const_cast regular in parameters... For out and inout, we don't have the problem...For simplicity, we should always allows modifications (at the outer level). In each cases, we may want to add modifier to data (and pointer member) of class type arguments... so that some member may always be modified (mutable) or never be modified (const). When declaring data, immuable would mean that the data will never be modified (physically) while const would applys to visible state. For immuable data, the compiler would be allowed to optimize construction by optimizing the constructor to minimize run-time execution by doing compile-time initialisation if possible. So in resume, my suggestion is that modifier works essentially as they do in C++ but we would have 1 more keyword to represent stricter constness and when data keyword is used, the compiler would not allows const_cast and assumes not external modifications except if the argument is declared also mutable). Some examples to help clarify the idea (this is not a complete analysis) void f1(in int a); // a is const (similar to const & in C++ - if a is modified, changes need not to propagate back but can) void f2(in immuable int a); // also physically const and const_cast not allowed... (if we don't want 1 more keyword...) void f3(in volatile int a); // can be modified externally - compiler must not optimize access void f4(out immuable int a); // cannot be modified externally void f5(inout const int a); // same as in int a but will always propagate changes back if const_cast is used... Some other combinaisons are allowed and some are prohibited... It may be possible that some keyword impies other one (immuable implies const except for out parameter (if supported with the above meaning)) Some other keyword may also be used: byref (or &) and/or byvalue. Also, we may have variable (or var) and we should also support the move-constructor idiom with another keyword (transfert) or by a predefined operator (or member)...
 Add to that the several subtilities in C++ regarding const (things like

 compiler implicitly converting values to const references if need be,

 is useful, but somewhat awkward really) and I can very well understand why
 a compiler writer wouldn't see much benefit in it.

 Another could relying for run-time guarantees: placing the const data
 in a page with only read-only access, and turning hardware exceptions
 into D exceptions if possible. This is what C++ does (in addition to
 static guarantees of const) and that's my personal preference, too.

This does not work with the conceptual const-ness approach, which limits

 usefulness of const quite dramatically.

 -fg

Aug 14 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhggt3$fiq$1 digitaldaemon.com>, Fabian Giesen wrote:
 Antti Sykäri wrote:
 So the main question is, should one make a programming language that
 will make programming fun, or one that allows for as strict static
 guarantees as possible?

The C++ const doesn't make any strict static guarantees, that's why it's worthless for a compilers' optimizer and also why it ultimately is only an annoyance. In C++, not only can anyone cast away constness, there's not even a clear consensus on what actually *is* const. Some go for "no byte is ever changed", some go for "no outside visible state is ever changed".

There's no point arguing about the meaning of const, just look up the definition in the standard. Which in this case says: - trying to change any (member of an) object through a const-qualified access path (e.g. a pointer of type const T*) is an error - however, you can work around the type system using const_cast<> - but still, an attempt to change an const object results in undefined behavior with the exceptions of mutable members, which you in fact can change. So the standard says that if we've got pointer to a const object, we can't change it, but does not indeed say the object would be immutable. Which is quite convenient: when you call a function with signature void f(const T*); you can be certain that it won't change your argument. -A.
Aug 15 2003
next sibling parent reply "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise. -fg
Aug 16 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
I would vote that it would not be possible to cast away constness... but
then
the problem is that if someone forget some const in a library and I uses
that
library, I will not be able to call those functions..

In fact, it would preferable to have const by default and having to specify
it explictly when we want to allows modification (this would also apply to
member functions). For inout and out parameter, the rule would be different.
If there are only one implicit-indirection level, that level would not be
const.

Same for member functions....


Or better if it is possible would be that the default is detected by the
compiler
and user can add modifier if he want to force something. This could include
the possibility of byref, const, variable (var), constness_of, byvalue,
volatile,
mutable and immuable... (in addition to existing in, inout and out). Also,
we should be able to specify if null (empty, 0) is allowed and default.

I think that we should at least have the attribute that we can specify for
parameters of a COM method in an IDL file.

When nothing is specified, value semantic would be used if the compiler
cannot prove that something won't get modified by an in parameter
(or by a member function call).


"Fabian Giesen" <rygNO SPAMgmx.net> a écrit dans le message de
news:bhmc8c$h12$1 digitaldaemon.com...
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise. -fg

Aug 16 2003
prev sibling next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhmc8c$h12$1 digitaldaemon.com>, Fabian Giesen wrote:
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise.

You can be pretty certain that the callee won't cast your constness away without being sure that the object isn't actually const-qualified, since the object could be const-qualified and located in a read-only segment. If it is, trying to modify it through a non-const pointer will cause undefined behavior -- in practice, segmentation fault. -Antti
Aug 17 2003
parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbjuvvn.man.jsykari pulu.hut.fi...
 In article <bhmc8c$h12$1 digitaldaemon.com>, Fabian Giesen wrote:
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise.

You can be pretty certain that the callee won't cast your constness away without being sure that the object isn't actually const-qualified, since the object could be const-qualified and located in a read-only segment. If it is, trying to modify it through a non-const pointer will cause undefined behavior -- in practice, segmentation fault.

fault they may quitely not change things (Rom'ed object on an embedded target). in all you are just justifying the point that c++ const is a meaninlessly vague promise. what it wanted is a concrete callee promise that they will not modify under any condition (the caller or other may [which is the root of the problem])
Aug 17 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bho1ia$2ro1$1 digitaldaemon.com>, Mike Wynn wrote:
 
 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbjuvvn.man.jsykari pulu.hut.fi...
 In article <bhmc8c$h12$1 digitaldaemon.com>, Fabian Giesen wrote:
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise.

You can be pretty certain that the callee won't cast your constness away without being sure that the object isn't actually const-qualified, since the object could be const-qualified and located in a read-only segment. If it is, trying to modify it through a non-const pointer will cause undefined behavior -- in practice, segmentation fault.

fault they may quitely not change things (Rom'ed object on an embedded target). in all you are just justifying the point that c++ const is a meaninlessly vague promise. what it wanted is a concrete callee promise that they will not modify under any condition (the caller or other may [which is the root of the problem])

It's just a question of the proportion of trust you are ready to place on the contract (or the promise) that the function declaration "f(const T*)" has. "I won't modify my argument." The const keyword is a way to state that clearly and concisely. If you would want to ban const_cast to make that a "concrete guarantee" instead of a promise, you'd have to ban unions, inline assembly, foreign function interfaces and all those good old dangerous features, because they can all be used to subvert constness. As for the "vague promise" that const keyword gives... Is it, by analogy, a "vague promise" that you will end up in jail if you commit a murder? You might get away with it (if the police don't catch you or if you happened to cast away the constness of an object that actually wasn't const) or then you might get caught (if the object actually was in a read-only segment). People don't usually go around killing other people, firstly because usually there's no particular reason to do that. Secondly, doing that might have dire consequences -- undefined behavior if you will. And you don't break the unspoken rules of a programming language either, or if you do, you face the consequences. I'm not going to give any reasons why it would be a good idea for anyone to kill someone (we already had a religious discussion about goto; no need to bring abortion, euthanasia or death penalty into the picture now), but sometimes it's needed to cast away the constness and therefore C++ has standard, working, well-documented const_cast operator for that purpose. Anyway, my point, if it didn't state it clearly enough, was that no one in their sane mind would do, for example, this: cheater.h: -------------------------- // I promise not to touch str void cheater(const char* str); -------------------------- cheater.cpp: -------------------------- void cheater(const char* str) { char* cheat = const_cast<char*>(str); // Ha-ha! A little trick, hopefully no one will notice. cheat[0] = 'x'; } -------------------------- The reason being: main.cpp: -------------------------- #include "cheater.h" #include "stdio.h" int main(int argc, char* argv[]) { if (argc < 2) return 1; const char* str; if (strcmp(argv[1], "1") == 0) { const char const_string[] = "abc"; str = const_string; } else if (strcmp(argv[1], "2") == 0) { char non_const_string[] = "abc"; str = non_const_string; } else if (strcmp(argv[1], "3") == 0) { str = "abc"; } cheater(str); printf("str = %s\n", str); } -------------------------- jsykari:~% mv a.cc main.cc jsykari:~% g++ main.cc -o main jsykari:~% ./main 1 str = xbc jsykari:~% ./main 2 str = xbc jsykari:~% ./main 3 zsh: segmentation fault ./main 3 Whoops! One of the general rules that guided the development of C++ was "Don't try to force people" (quote from D&E): "Programmers are smart people. They are engaged in challenging tasks and need all the help they can get from a programming language as well as from other supporting tools and techniques. Trying to seriously constrain programmers to do "only what is right" is inherently wrongheaded and will fail. Programmers will find a way around rules and restrictions they find unacceptable." I hope that D is not heading in a radically different direction. Oh, and by the way, same applies for the dreaded goto statement. -Antti
Aug 17 2003
next sibling parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbjvjf1.pru.jsykari pulu.hut.fi...
 "Programmers are smart people. They are engaged in challenging tasks and
 need all the help they can get from a programming language as well as
 from other supporting tools and techniques. Trying to seriously
 constrain programmers to do "only what is right" is inherently
 wrongheaded and will fail. Programmers will find a way around rules and
 restrictions they find unacceptable."

 I hope that D is not heading in a radically different direction.

 Oh, and by the way, same applies for the dreaded goto statement.

you are argueing for it ! D does not have const params, and the above statement implies that it should never have const params (or final [java]). to me your argument actually agrees with "const it just a vague promise" so effectively useless. and not all platform have exceptions on write to location 0; *((char*)0) = 'A'; can work the same as on some platforms write into read only areas just has no effect.
Aug 17 2003
prev sibling next sibling parent "Matthew Wilson" <matthew stlsoft.org> writes:
Perfectly put! I agree.


"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbjvjf1.pru.jsykari pulu.hut.fi...
 In article <bho1ia$2ro1$1 digitaldaemon.com>, Mike Wynn wrote:
 "Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
 news:slrnbjuvvn.man.jsykari pulu.hut.fi...
 In article <bhmc8c$h12$1 digitaldaemon.com>, Fabian Giesen wrote:
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise.

You can be pretty certain that the callee won't cast your constness



 without being sure that the object isn't actually const-qualified,



 the object could be const-qualified and located in a read-only segment.
 If it is, trying to modify it through a non-const pointer will cause
 undefined behavior -- in practice, segmentation fault.

fault they may quitely not change things (Rom'ed object on an embedded target). in all you are just justifying the point that c++ const is a


 vague promise.
 what it wanted is a concrete callee promise that they will not modify


 any condition
 (the caller or other may [which is the root of the problem])

It's just a question of the proportion of trust you are ready to place on the contract (or the promise) that the function declaration "f(const T*)" has. "I won't modify my argument." The const keyword is a way to state that clearly and concisely. If you would want to ban const_cast to make that a "concrete guarantee" instead of a promise, you'd have to ban unions, inline assembly, foreign function interfaces and all those good old dangerous features, because they can all be used to subvert constness. As for the "vague promise" that const keyword gives... Is it, by analogy, a "vague promise" that you will end up in jail if you commit a murder? You might get away with it (if the police don't catch you or if you happened to cast away the constness of an object that actually wasn't const) or then you might get caught (if the object actually was in a read-only segment). People don't usually go around killing other people, firstly because usually there's no particular reason to do that. Secondly, doing that might have dire consequences -- undefined behavior if you will. And you don't break the unspoken rules of a programming language either, or if you do, you face the consequences. I'm not going to give any reasons why it would be a good idea for anyone to kill someone (we already had a religious discussion about goto; no need to bring abortion, euthanasia or death penalty into the picture now), but sometimes it's needed to cast away the constness and therefore C++ has standard, working, well-documented const_cast operator for that purpose. Anyway, my point, if it didn't state it clearly enough, was that no one in their sane mind would do, for example, this: cheater.h: -------------------------- // I promise not to touch str void cheater(const char* str); -------------------------- cheater.cpp: -------------------------- void cheater(const char* str) { char* cheat = const_cast<char*>(str); // Ha-ha! A little trick, hopefully no one will notice. cheat[0] = 'x'; } -------------------------- The reason being: main.cpp: -------------------------- #include "cheater.h" #include "stdio.h" int main(int argc, char* argv[]) { if (argc < 2) return 1; const char* str; if (strcmp(argv[1], "1") == 0) { const char const_string[] = "abc"; str = const_string; } else if (strcmp(argv[1], "2") == 0) { char non_const_string[] = "abc"; str = non_const_string; } else if (strcmp(argv[1], "3") == 0) { str = "abc"; } cheater(str); printf("str = %s\n", str); } -------------------------- jsykari:~% mv a.cc main.cc jsykari:~% g++ main.cc -o main jsykari:~% ./main 1 str = xbc jsykari:~% ./main 2 str = xbc jsykari:~% ./main 3 zsh: segmentation fault ./main 3 Whoops! One of the general rules that guided the development of C++ was "Don't try to force people" (quote from D&E): "Programmers are smart people. They are engaged in challenging tasks and need all the help they can get from a programming language as well as from other supporting tools and techniques. Trying to seriously constrain programmers to do "only what is right" is inherently wrongheaded and will fail. Programmers will find a way around rules and restrictions they find unacceptable." I hope that D is not heading in a radically different direction. Oh, and by the way, same applies for the dreaded goto statement. -Antti

Aug 18 2003
prev sibling parent reply "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 As for the "vague promise" that const keyword gives...

 Is it, by analogy, a "vague promise" that you will end up in jail if
 you commit a murder?  You might get away with it (if the police don't
 catch
 you or if you happened to cast away the constness of an object that
 actually wasn't const) or then you might get caught (if the object
 actually was in a read-only segment).

 People don't usually go around killing other people, firstly because
 usually there's no particular reason to do that.  Secondly, doing that
 might have dire consequences -- undefined behavior if you will.  And
 you don't break the unspoken rules of a programming language either,
 or if
 you do, you face the consequences.

This is beside the point of what I'm trying to say. The question is why there is a compelling need for const. I only see an use for const if it's an actual guarantee and the compiler can rely on it and act accordingly (put all const data into readonly segments, assume that anything declared const is really constant for its whole lifetime). In C++, it can't, which is why I don't see much point with doing const like it is in C++. If the language supports this kind of interface specifications, but cannot make use of it or enforce correct usage, I don't see the reason for adding the specification in the first place. That would be like adding an inout_cast to make "in" parameters inout in certain cases. I agree that such limitations can always be worked around with inline assembler or union hacks or stuff like that, but that's not of interest to me; if you have to go into the realm of undefined behavior in the first place to do something, it's perfectly okay if you get undefined behavior in return. :) As for const, that's a software design issue IMHO. If you add const, then make it rigid. Mutables are okay, because those are also part of the interface specification and thus also documented and acceptable. Functions that claim they have const objects and still modify them aren't, because in that case the interface specification mismatches the actual interface. All uses of const_cast I've seen so far in C++ code (with C++ compilers that did support mutable) were basically quick&dirty hacks because of people either not wanting to change the interface to get a non-const parameter or people not wanting to make variables mutable and suffer LONG recompile times in big projects because a central header changed. The second is purely a problem of the C/C++ compilation model and not relevant in that way to D; and the first is something a language that employs design by contract should prevent. After all, modifying a variable that's supposed to be const is a far more basic violation of the interface specification and contract than returning a wrong value in 0.1% of all cases :) -fg
Aug 18 2003
next sibling parent reply "Peter Hercek" <vvp no.post.spam.sk> writes:
"Fabian Giesen" <rygNO SPAMgmx.net> wrote in message
news:bhrn8p$251q$1 digitaldaemon.com...
 As for the "vague promise" that const keyword gives...

 Is it, by analogy, a "vague promise" that you will end up in jail if
 you commit a murder?  You might get away with it (if the police don't
 catch
 you or if you happened to cast away the constness of an object that
 actually wasn't const) or then you might get caught (if the object
 actually was in a read-only segment).

 People don't usually go around killing other people, firstly because
 usually there's no particular reason to do that.  Secondly, doing that
 might have dire consequences -- undefined behavior if you will.  And
 you don't break the unspoken rules of a programming language either,
 or if
 you do, you face the consequences.

This is beside the point of what I'm trying to say. The question is why there is a compelling need for const. I only see an use for const if it's an actual guarantee and the compiler can rely on it and act accordingly (put all const data into readonly segments, assume that anything declared const is really constant for its whole lifetime).

I don't think it needs to be a guarantee. I look at const more as a domumentation feature of language with a few good sideeffects: 1) library optimizations possible 2) support for proxy generation is more efficient (you do not need to marshal const references both ways) 3) may be some compiler optimizations too The documentation feature is the most important. I express what is my intention by placing there const. Also comments are not guarantee that the code really does what is written in them. Anyway most porgrammers think comments are good (or am I naive here?). Without const your input only reference type argument is not really input, but in-out (or something in between) and you do not have any help from compiler here at all. Full const is nice, but probably useless if compiler does not report errors/warnings on places where const should be put, but was not in the actual code ... or some other help in this matter. Programmers are too lazy.
Aug 18 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 I don't think it needs to be a guarantee. I look at const more as a

  feature of language with a few good sideeffects:
 1) library optimizations possible
 2) support for proxy generation is more efficient (you do not need to

    const references both ways)
 3) may be some compiler optimizations too

 The documentation feature is the most important. I express what is my

  by placing there const. Also comments are not guarantee that the code

  does what is written in them. Anyway most porgrammers think comments
  are good (or am I naive here?).
 Without const your input only reference type argument is not really input,
  but in-out (or something in between) and you do not have any help from
  compiler here at all.
 Full const is nice, but probably useless if compiler does not report

  on places where const should be put, but was not in the actual code ...

  some other help in this matter. Programmers are too lazy.

I agree with that... Maybe for library implementation, it could be usefull to have keyword (or attributes) that would better control what it is allowed... For ex. a function parameter might be declared "immuable" or "strict const" to tell the compiler that it cannot be modified under any circumpstance. Personnaly, I think that extra attributes (as in IDL and .NET) could be uses to write highly optimized library but would not be used in typical user program. This could be compared to some advanced optimisations in C++ with boost, move constructors, and compiler traits (is_class, is_enum, is_POD,...) that allows to make the STL more efficients.
Aug 19 2003
prev sibling next sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhrn8p$251q$1 digitaldaemon.com>, Fabian Giesen wrote:
 People don't usually go around killing other people, firstly because
 [ ... ]

This is beside the point of what I'm trying to say. The question is why there is a compelling need for const. I only see an use for const if it's an actual guarantee and the compiler can rely on it and act accordingly (put all const data into readonly segments, assume that anything declared const is really constant for its whole lifetime).

Point taken. I didn't particularly try to advocate "const" as it is in C++, just wanted to point out that while it might play a role of a vague promise to the compiler, this is not the case for the programmer (and, importantly, maintainer), who enjoys the benefits of increased type information. I'm not sure if const is at all needed. Personally I've been a happy user of const ever since I learned C++ and haven't really tried to live without const (with the exception of occasional straying to the Java side). So I'd rather trust the opinions of the more experienced programmers. Meanwhile, let us concentrate for a moment on the meaning of const. Conceptually, the const as we know it in C++ offers a read-only access to the object. If we leave basic types and structs out of the picture, and just look at classes, we can implement it by separating the class' interface into read-only interface and the rest. If the class is already accessed via virtual functions (like a proper class should), this doesn't even impose any extra costs. "Const" access to the class can be provided by explicitly returning the read-only interface of the class, and this is in fact what happens when you specify a "const T" in C++: you actually get an object of type T, but can effectively access only the subset of member functions which are explicitly marked "const". This is also an issue that needs to be taken into consideration when designing the basic container library for D. Java, a blatant mockery of static typing, solves the "const" by providing a view to the container (via java.util.Collections.unmodifiableCollection or similar) which looks exactly like the original, but throws an UnsupportedOperationException when one tries to modify it. No wonder there's a project trying to bring "const" to Java (http://pag.lcs.mit.edu/constjava/). At any case, if the language has no const and someone wants non-writable containers, (and someone definitely will), the library designer must balance between proliferation of const interfaces and the risk of run-time errors. In C++ he could just leave the complication up to the language. Oh, and then there are the basic types which are left without any protection. But I suppose one can get away with some kind of boxing. And nobody wants to pass small values by const-qualified pointers anyway, so they are kind of non-issue. As a side note, "const" was originally proposed in 1981 and was called "readonly", and there was also "writeonly". (To mirror the properties of r/w bits in the memory controller; possibly memory-mapped hardware registers) The standardization process changed "readonly" to "const" and dropped "writeonly".
 As for const, that's a software design issue IMHO. If you add const,
 then make it rigid. Mutables are okay, because those are also part of
 the interface specification and thus also documented and acceptable. 

So assume that we'd have these kind of strictly constant / rigidly constant / guaranteed to have the same value objects. "immutable" would not be a bad term, IMO, so I'll use it from now on. I can distantly see some consequences: - compiler could probably do some optimizations better - object of type T cannot be assigned to variable of type immutable T; to produce an immutable T you either have to clone it or have it be immutable from the beginning - there *will* be cases where the programmer wants to cast a T to immutable T because he simply knows that the object won't change. Should a simple cast like ((immutable T) t) suffice? - there would have to be methods with immutable modifier, which would comprise the immutable object's interface - plus the added complexity of overloading + other stuff that Walter has used as an argument against const All of this would complicate the language somewhat; but probably only after implementing and experimenting you would know whether it would be worth it. Are there any languages out there (except the purely functional ones) with immutable values? Now that I think of it, I remember that Daniel Yokomiso wrote an interesting description of const stuff some time ago, let's see... There, I see it's still worth reviewing: D/9962 (Daniel: how's Eon doing, by the way?) -Antti
Aug 19 2003
next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> a écrit dans le message de
news:slrnbk5c5l.4q6.jsykari pulu.hut.fi...
 In article <bhrn8p$251q$1 digitaldaemon.com>, Fabian Giesen wrote:
 People don't usually go around killing other people, firstly because
 [ ... ]

This is beside the point of what I'm trying to say. The question is why there is a compelling need for const. I only see an use for const if


 actual guarantee and the compiler can rely on it and act accordingly


 all const data into readonly segments, assume that anything declared


 is really constant for its whole lifetime).

Point taken. I didn't particularly try to advocate "const" as it is in C++, just wanted to point out that while it might play a role of a vague promise to the compiler, this is not the case for the programmer (and, importantly, maintainer), who enjoys the benefits of increased type information. I'm not sure if const is at all needed. Personally I've been a happy user of const ever since I learned C++ and haven't really tried to live without const (with the exception of occasional straying to the Java side). So I'd rather trust the opinions of the more experienced programmers. Meanwhile, let us concentrate for a moment on the meaning of const.

I do think that we need some kind of const access weither it is usefull or not for the compiler. It is usefull for the programmer. Making it strictier would make it even more usefull but library writers would have to do it right!
 As for const, that's a software design issue IMHO. If you add const,
 then make it rigid. Mutables are okay, because those are also part of
 the interface specification and thus also documented and acceptable.

So assume that we'd have these kind of strictly constant / rigidly constant / guaranteed to have the same value objects. "immutable" would not be a bad term, IMO, so I'll use it from now on. I can distantly see some consequences: - compiler could probably do some optimizations better - object of type T cannot be assigned to variable of type immutable T; to produce an immutable T you either have to clone it or have it be immutable from the beginning

So your definition of immuable that an object won't changes... but for a function parameter, does it apply to both the source and target or only to the target (as const in C++).
 - there *will* be cases where the programmer wants to cast a T to
   immutable T because he simply knows that the object won't change.
   Should a simple cast like ((immutable T) t) suffice?

 - there would have to be methods with immutable modifier, which would
   comprise the immutable object's interface

 - plus the added complexity of overloading + other stuff that Walter has
   used as an argument against const

For overloadding, we should then have a way to reuse the same code for all variations if applicable. typical case would be to be able to select the appropriate constness of the return value of a member function... I think that the compiler could automatically make the result const if this is required (for ex. when returning an element from a const container). class E; class C { E &get() { return member; } E member; } Here if get is called on a const C, the compiler could add const to E if otherwise the function would compile if it were const. Doing it that way would avoid most of the complexity of overloadding in C++ where we need to provide both a const and a regular version of the same function. Also, the programmer won't be required to put all const... The compiler would be able to do some analysis to verify if a function can be generated. And with prohibited keyword that I suggest in another thread, one would be able to prohibit using the const version if he wants (for example for a swap function, we don't want const parameter and prohibiting it would do that the compiler won't have to continue analysis...) I would opt for smart constness and a few modifier when they are required. I would add prohibited and immuable and borrow const and mutable from C++... prohibited would be a function modifier that will ensure that the function is never called. immuable would be a parameter modifier that would be more strict than const (no const_cast possible)
 All of this would complicate the language somewhat; but probably only
 after implementing and experimenting you would know whether it would be
 worth it.

 -Antti

Aug 19 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhug4k$78v$1 digitaldaemon.com>, Philippe Mori wrote:
 As for const, that's a software design issue IMHO. If you add const,
 then make it rigid. Mutables are okay, because those are also part of
 the interface specification and thus also documented and acceptable.

So assume that we'd have these kind of strictly constant / rigidly constant / guaranteed to have the same value objects. "immutable" would not be a bad term, IMO, so I'll use it from now on. I can distantly see some consequences: - compiler could probably do some optimizations better - object of type T cannot be assigned to variable of type immutable T; to produce an immutable T you either have to clone it or have it be immutable from the beginning

So your definition of immuable that an object won't changes... but for a function parameter, does it apply to both the source and target or only to the target (as const in C++).

What do you mean by source and target in this context? Immutable's just an object that will never change after it has been initialized.
 - there *will* be cases where the programmer wants to cast a T to
   immutable T because he simply knows that the object won't change.
   Should a simple cast like ((immutable T) t) suffice?

 - there would have to be methods with immutable modifier, which would
   comprise the immutable object's interface

 - plus the added complexity of overloading + other stuff that Walter has
   used as an argument against const

For overloadding, we should then have a way to reuse the same code for all variations if applicable. typical case would be to be able to select the appropriate constness of the return value of a member function... I think that the compiler could automatically make the result const if this is required (for ex. when returning an element from a const container). class E; class C { E &get() { return member; } E member; } Here if get is called on a const C, the compiler could add const to E if otherwise the function would compile if it were const. Doing it that way would avoid most of the complexity of overloadding in C++ where we need to provide both a const and a regular version of the same function. Also, the programmer won't be required to put all const... The compiler would be able to do some analysis to verify if a function can be generated.

Can you elaborate your ideas a bit? I'd be interested to see an example which would show that your idea works in practice. IMO, Autogenerating methods at compile-time where "const" needed seems complex and it might cause some overhead. For example, class interfaces would need to have const version for each method. For example, what if your example was derived for an interface: class C; interface C_Interface { E get(); // Compiler must autogenerate this in order to any derived C to work:: const E get() const; } class C : C_Interface { E get() { return member; } // Compiler needs to generate E get() { return member; } E member; } class C2 : C_Interface { E get() { return new E(); } // This one will always non-const E always, but how does the client // know that if it accesses a C_Interface object? // Back to the drawing board - need to add "E get() const;" function // to C_Interface. Too much bloat }
 And with prohibited keyword that I suggest in another thread, one would be
 able to prohibit using the const version if he wants (for example for a swap
 function, we don't want const parameter and prohibiting it would do
 that the compiler won't have to continue analysis...)

I still don't see much use for the "prohibit" keyword. It would mostly be useful if the compiler would auto-generate a lof of functions (such as copy constructors, assignment operators in C++) and there would be a need for not having them.
 prohibited would be a function modifier that will ensure that the function
 is never called.

Then why put the function there in the first place? :) -A
Aug 23 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 So your definition of immuable that an object won't changes... but for
 a function parameter, does it apply to both the source and target or
 only to the target (as const in C++).

What do you mean by source and target in this context? Immutable's just an object that will never change after it has been initialized.

Suppose something similar to this: void f(int &target) { ... } int source = 1; f(source); The source is from where the data come... Can source be modified externally (other thread, alias, while f is executing. Target is what we do inside the function... Maybe not the best terms... It is the perspective from either side (i.e. inside the function, can I assumes that the received object is constant and do some optimisation in consequence, does I have the possibility to modify the source object (possibly with a cast, or the object is really const (unmodifiable) or a copy.... So one might like to tell that the source cannot change (even externally) and another one might tell that target won't change...
 I think that the compiler could automatically make the result const
 if this is required (for ex. when returning an element from a const
 container).


 Also, the programmer won't be required to put all const... The compiler
 would be able to do some analysis to verify if a function can be


 Can you elaborate your ideas a bit? I'd be interested to see an example
 which would show that your idea works in practice.  IMO, Autogenerating
 methods at compile-time where "const" needed seems complex and it might
 cause some overhead. For example, class interfaces would need to have
 const version for each method. For example, what if your example was
 derived for an interface:

OK, I see my error... Essentially, it would only be possible to do such analysis for final method.... For all other method, it does not works well. In fact, const is most appropriate for concrete (final) and simple type that can be checked at compile-time... and maybe we should support const only for those types (so that for ex. if we pass a constant container (that would be a concrete type), we would be able to prevent modification to the container... This also means that for templates like a container, we want a concrete class that is final (no possible override)...
 And with prohibited keyword that I suggest in another thread, one would


 able to prohibit using the const version if he wants (for example for a


 function, we don't want const parameter and prohibiting it would do
 that the compiler won't have to continue analysis...)

I still don't see much use for the "prohibit" keyword. It would mostly be useful if the compiler would auto-generate a lof of functions (such as copy constructors, assignment operators in C++) and there would be a need for not having them.
 prohibited would be a function modifier that will ensure that the


 is never called.

Then why put the function there in the first place? :)

I see a few cases: - The functions is implictly generated - There are some implicit conversion that are allowed but does not give the desired result (for ex. in C++ std::string class can be initialized from 0.0 or false because of implicit conversion that occurs but are not desirable in that specific context). In practice, if we find such a bug, then we have an easy way to ensure we won't have it another time. - One existing function become obsolete and we want to ensure that it is not used anymore but because there are other similar overload we like the compiler to trap them and issue an error. A keyword allows to make it clearer... Otherwise it is possible to do it with templates but it is more complicated... - In generic (template) code, we might know some undesired types for arguments (like swapping one constant object or swapping objects of distincts type). If we have a prohibited keyword, it is a lot easier to prohibit what we don't want that to make code that would causes a compilation error in those cases... I have done it (preventing code from compiling) a lot of times in C++ when I was refactoring the code that have known problems. I was using the compiler to help me find those problematic places...
Aug 23 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bi9df5$1bh7$1 digitaldaemon.com>, Philippe Mori wrote:
 
 So your definition of immuable that an object won't changes... but for
 a function parameter, does it apply to both the source and target or
 only to the target (as const in C++).

What do you mean by source and target in this context? Immutable's just an object that will never change after it has been initialized.

Suppose something similar to this: void f(int &target) { ... } int source = 1; f(source); The source is from where the data come... Can source be modified externally (other thread, alias, while f is executing.

If it's immutable, then it cannot. If it's mutable, like in your example, it can. This also means that there is an fundamental incompatibility between mutable and immutable objects: one cannot be converted to the other, at least not without violating the basic rules of the language. (References changed to inout to look more like D. After all, this is a D newsgroup...) void f(inout immutable int); int source = 1; f(source); // compile-time error: can't convert int to immutable int If you could do the conversion, you might be able to change the object in another thread or via aliasing, and it would change without f() knowing. Which would make immutable the same as C++'s const, and prevent the precious compiler optimizations that we're trying to achieve here (or, are we? I actually doubt that they'd be so significant)
 prohibited would be a function modifier that will ensure that the
 function is never called.

Then why put the function there in the first place? :)

I see a few cases: - The functions is implictly generated

I guess there aren't implicitly generated functions in D currently (I might be wrong?)
 - There are some implicit conversion that are allowed but does not
 give the desired result (for ex. in C++ std::string class can be
 initialized from 0.0 or false because of implicit conversion that
 occurs but are not desirable in that specific context). In practice,
 if we find such a bug, then we have an easy way to ensure we won't
 have it another time.

I think D doesn't have as many opportunities to shoot oneself in the foot as C++, particularly with respect to implicit conversions... Then again, maybe there is someone to know better.
 - One existing function become obsolete and we want to ensure that
 it is not used anymore but because there are other similar overload
 we like the compiler to trap them and issue an error. A keyword
 allows to make it clearer...  Otherwise it is possible to do it with
 templates but it is more complicated...

D has deprecated: http://www.digitalmars.com/d/attribute.html
 - In generic (template) code, we might know some undesired types
 for arguments (like swapping one constant object or swapping
 objects of distincts type). If we have a prohibited keyword, it
 is a lot easier to prohibit what we don't want that to make code
 that would causes a compilation error in those cases...

You might be wanting to abuse the deprecated (or private) qualifiers to do that kind of prohibiting. All of those keywords would play partly the same role, which isn't exactly orthogonal language design. I'd rather go in the direction of general compile-time error message which can have a lot more uses than just prohibiting instantiation of a certain function. class X { } template (Foo) { // your general template code goes here } template (Foo : X) { compileTimeError("You shouldn't instantiate Foo with types derived " "from X"); } Upon finding an "instance Foo(X)" the compiler would blurt out something like line 567: Cannot instantiate Foo(X) line 123: compileTimeError: You shouldn't instantiate Foo with types derived from X
 I have done it (preventing code from compiling) a lot of times in
 C++ when I was refactoring the code that have known problems.
 I was using the compiler to help me find those problematic places...

If you can find an example that isn't solved by other features in D, people are likely to be interested in seeing it. -Antti
Aug 24 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 If it's immutable, then it cannot. If it's mutable, like in your
 example, it can. This also means that there is an fundamental
 incompatibility between mutable and immutable objects: one cannot be
 converted to the other, at least not without violating the basic rules
 of the language.

 (References changed to inout to look more like D. After all, this is a D
 newsgroup...)

 void f(inout immutable int);
 int source = 1;
 f(source); // compile-time error: can't convert int to immutable int

If I want to uses an in parameter, does I have the choice between by value which I think is the default and by reference... So it would be more like void f(in byref immutable int) // More D style syntax or void f (in immutable & int the_param) // More like C++ To tell the compiler that I do not want to modify the_param and that it can assumes that it won't be modified externally.
 If you could do the conversion, you might be able to change the object
 in another thread or via aliasing, and it would change without f()
 knowing. Which would make immutable the same as C++'s const, and prevent
 the precious compiler optimizations that we're trying to achieve here
 (or, are we? I actually doubt that they'd be so significant)

 I guess there aren't implicitly generated functions in D currently (I
 might be wrong?)

 - There are some implicit conversion that are allowed but does not
 give the desired result (for ex. in C++ std::string class can be
 initialized from 0.0 or false because of implicit conversion that
 occurs but are not desirable in that specific context). In practice,
 if we find such a bug, then we have an easy way to ensure we won't
 have it another time.

I think D doesn't have as many opportunities to shoot oneself in the foot as C++, particularly with respect to implicit conversions... Then again, maybe there is someone to know better.
 - One existing function become obsolete and we want to ensure that
 it is not used anymore but because there are other similar overload
 we like the compiler to trap them and issue an error. A keyword
 allows to make it clearer...  Otherwise it is possible to do it with
 templates but it is more complicated...

D has deprecated: http://www.digitalmars.com/d/attribute.html

But does it is possible to control in which module or on some other condition when deprecated take effects. Maybe I am using 2 libraries that has some deprecated functions but I still want to uses them in the first one (the code depends a lot on them) but not on the second one... Also if the attribute can be depedant on other things (probably on versioning), then it might be possible to uses version for that purpose...
 - In generic (template) code, we might know some undesired types
 for arguments (like swapping one constant object or swapping
 objects of distincts type). If we have a prohibited keyword, it
 is a lot easier to prohibit what we don't want that to make code
 that would causes a compilation error in those cases...

You might be wanting to abuse the deprecated (or private) qualifiers to do that kind of prohibiting. All of those keywords would play partly the same role, which isn't exactly orthogonal language design. I'd rather go in the direction of general compile-time error message which can have a lot more uses than just prohibiting instantiation of a certain function. class X { } template (Foo) { // your general template code goes here } template (Foo : X) { compileTimeError("You shouldn't instantiate Foo with types derived " "from X"); } Upon finding an "instance Foo(X)" the compiler would blurt out something

 line 567: Cannot instantiate Foo(X)
 line 123: compileTimeError: You shouldn't instantiate Foo with types
 derived from X

Compile time error is a must... This allows to check many constraints that are not directly supported by the language (like your example). This can be used to validate some constants to ensure no accidental changes would be done. This include some magic numbers, the size of a structure (it's alignment, member offset,...) and we should be able also to check some properties of classes and struct like: - Is it a POD type, auto type, class type, enum type,... - Is it modifiable - Does it have a given member or support a given operation (member function, copy constructor, default constructor, operator +, comparison, equality,...) - Is if final, abstract,... - Is it an interface (or a COM compatible interface)
 I have done it (preventing code from compiling) a lot of times in
 C++ when I was refactoring the code that have known problems.
 I was using the compiler to help me find those problematic places...

If you can find an example that isn't solved by other features in D, people are likely to be interested in seeing it.

I haven't yet tried the D compiler but I think that it might be interesting to check what can be done in D form the following source (and others): - Modern C++ Design (book) & Loki - C++ Templates (book) - STL - boost - ATL - C#, .NET and managed C++ - Xena ... We would then be able to compare the power and the simplicity of the language for some concrete things... and if something cannot be done directly, how hard it is to be done in D (if he can be done) or is it necessary (or we have better alternatives). It would also be interesting to check from some of well known book like Effective C++, Effective STL, and others that give some rules how to uses C++ more safely, how D compare (avoid problem at least implicitly while retaining enough power to be usefull...)
Aug 25 2003
next sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bid8ts$12qg$1 digitaldaemon.com>, Philippe Mori wrote:
 (References changed to inout to look more like D. After all, this is a D
 newsgroup...)

 void f(inout immutable int);
 int source = 1;
 f(source); // compile-time error: can't convert int to immutable int

If I want to uses an in parameter, does I have the choice between by value which I think is the default and by reference... So it would be more like void f(in byref immutable int) // More D style syntax

Whoops :) Of course immutable objects would be "in" since they cannot be changed. So I'd say: void f(in immutable int); or void f(in immutable Big_Object); Were this legal D, the compiler would be free to pick either by value or by reference (whichever it would think to be more efficient) -- the semantics wouldn't change. If it were const, the semantics _would_ change; consider int f(inout const int x, inout y) { y++; return x; } void main() { int a = 1; printf("%d\n", f(a, a)); } If f gets y and x by reference, main() will print 2, and if by value, it will print 1. This is one of the places where const can deceive. D doesn't specify by-reference or by-value, instead it relies on in/out/inout, as mentioned in the "Functions" section.
 D has deprecated: http://www.digitalmars.com/d/attribute.html

But does it is possible to control in which module or on some other condition when deprecated take effects. Maybe I am using 2 libraries that has some deprecated functions but I still want to uses them in the first one (the code depends a lot on them) but not on the second one...

Sounds like a quality of implementation issue; DMD has option: -d allow deprecated features I'd say that in this case, the answer is "yes" if you build the two projects separately. -Antti
Aug 25 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bid8ts$12qg$1 digitaldaemon.com...
 D has deprecated: http://www.digitalmars.com/d/attribute.html

condition when deprecated take effects.

No. It applies to any use of a function.
 Also if the attribute can be depedant on other things (probably
 on versioning), then it might be possible to uses version for
 that purpose...

That might work.
 class X { }

 template (Foo) {
     // your general template code goes here
 }
 template (Foo : X) {
     compileTimeError("You shouldn't instantiate Foo with types derived "
                      "from X");
 }

 Upon finding an "instance Foo(X)" the compiler would blurt out something

 line 567: Cannot instantiate Foo(X)
 line 123: compileTimeError: You shouldn't instantiate Foo with types
 derived from X

Compile time error is a must... This allows to check many constraints that are not directly supported by the language (like your example). This can be used to validate some constants to ensure no accidental changes would be done. This include some magic numbers, the size of a structure (it's alignment, member offset,...) and we should be able also to check some properties of classes and struct like:

This is now done with a new feature, static asserts.
Sep 19 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
I'm a heavy const user, a true believer in it, I'd say.  I'm going to throw
out some ideas:

How about adding another kind of access specifier, starting with readonly,
such that:

class A
{
    private T t;    // private data member
    readonly public:    // readonly section, also public.  this section
applies to both rvalues and lvalues of class A
        T GetT() { return t; }
    readwrite:  // go back to readwrite, still public.  This section applies
to lvalues
        this(in T t_) { t = t_; }
        T SetT(T other) { t = other; return this; }
}

A couple things I can see from the above:

It adds complexity to initialization.  I recommend just ignoring all
readonly accessors during a constructor, and maybe in the destructor too, or
in something obviously lvalue such as an assignment operator.

You can avoid having to constantly declare member functions const.  Just put
it in its own section.  This would save the "extra typing" overhead of C++
const quite a bit.

readonly and readwrite are a different set of attribute modifiers, totally
separate from private public and protected.  Orthogonal to.  Unrelated.  So
readonly sections can overlap public/private sections, or be overlapped by
them.  readonly and readwrite might belong in the same category as mutable.

Public, private, protected control the visibility of names to everything
outside the class.  readonly and readwrite control how the class sees itself
(readonly interface, or readonly + readwrite interface) in those member
functions, and controls assignability of fields.  in, out, and inout control
readwrite access to parameters of those functions, and const declares
individual data rvalues, which aren't even castable to anything with write
access.  That's a lot of names for one basic concept (readonly-ness), so
perhaps it could all just be called const, or (lack of const) since the
usage situation would already make it unambiguous what you meant.

This readonly, for the builtin datatypes, and fundamentally, removes the
ability to use the assignment operator on such values, or call anything else
that's a readwrite member function, on that type.   It should also prevent
deletion or other forms of destruction/finalization.  And the compiler
should be able to treat copies of such a value made during periods in which
it is sure are all protected by that attribute, that they remain identical
so long as it knows the readonly attribute is attached to them.  When it
becomes unsure, it could save and reload it to make sure any changes are
reflected, but I'd rather guarantee that nothing will violate the
constraint, ever, during the lifetime of the object or data.  The compiler
should actively prevent the user from modifying such readonly values or
allowing them to be modified whenever possible.  If that's too restrictive,
use something like mutable, which has different behavior in different
situations.

I would like to have a kind of constructor that basically allowed the caller
to put whatever values they want into the class's fields, by name:

        this(in);   // how would you specify that you want the compiler to
generate a method for you, without having to specify any body?
                        // By using prototype only, no body, kinda like C++?
It would generate a method for you regardless in C++, but this way you get
to control the access.

I'd use it like so:

class Point
{
    float x,y,z;
    this(in);  // allow construction with the caller being able to
initialize the public fields and base class more or less directly
    this(float x_, float y_, float z_) { x = x_, y = y_, z = z_; } //
without that, you have to do this:
}

new Point a(x:1.0, y:2.0, z:0.0);   // call this(in) with initialization for
these members
new Point a(1.0, 2.0, 0.0);   // initialize fields by calling
this(float,float,float)

or

new Point a = { x:1.0; y:2.0, z:0.0 };  // same as this, which I think D
allows now?  D does named field initialization, right?

Maybe structs just automatically work that way.

And finally, like C#, I would like to be able to add my own attributes to
things.  Groups of attributes (private/public/protected would be a group,
and so would readonly/readwrite) declared sort of like enums.  Unlike
anything I've heard of before, you should be able to alias and aggregate
these attributes together (a global "alias private readonly
notevenIcantouchit;" or "alias public mutable youcanlookbutyoucanttouch").
If you could hook a couple prologue/epilog functions (inlined before and
after every function body) to these attributes, then use them to control
code generation the same way that contracts work now.

Even better, you could use such attributes to *implement* things like
contracts.

Think about it.  What if you declared something akin to an in and out
contract yourself?

attribute in_custom in { print("in"); assert(this->good()); }
attribute out_custom out { print("out"); assert(this->good()); }
alias attribute in_custom out_custom invariant_custom;

class Sign
{
    invariant_custom:
        private int x;
        public this() { x = 0; }
        bit good() { return x >= 0 && x <= 10; }
        void badfunction() { ++x; badfunction(); } // will recurse 10 times
and then trigger an assert exception!
}

The compiler would inject the attribute code into each function declared
after it

class Foo
{
    attribute {
        my_read assign { assert(false && "don't assign to my_read objects,
dumbass!"); }
        default my_readwrite { }
    };
        // everything up to this point is my_readwrite because it's the
default!
    my_read int x; // if you try to assign this, you'll assert!
    my_readwrite:
        // everything else goes here
}

So there are a bunch of basic "kinds" of modifiers such as in, out,
invariant, assign, destroy, copy, create, that sort of thing.  To control
what situations the code attached to the attribute would apply in.    Also
these attributes shouldn't run until the constructor for the object has
finished, and shouldn't run once the finalizer starts.  That way it's
guaranteed to have a complete object to deal with.

I don't think it would be a good idea to allow decorating member variables
with code.  Or would it?  A member variable or data attribute would control
things like assignment, reference, and might serve as an easy way to do
properties with a write-through or read-only data field.  (The properties in
the D spec now may never see the light of day!)

Maybe there should be some kind of compile time error for when the compiler
can detect at compile time that a code path is going to definitely be
executed that contains an assert statement (such as the assign assert above)
and issue a compile time error.

I guess all this adds to the complexity of the compiler.  That's a good
thing, in some ways.  This could be powerful stuff in the right hands.
Maybe could be combined with templates somehow?

It's really just the ability to add custom extra type information to your
types.

One of the major costs of maintenance is having code cut-and-pasted in a
bunch of places, as it is hard to change something if it's scattered all
over the place.  With attributes you can write boilerplate code and attach
it to things with an attribute in its declaration.  This is good because it
keeps such code in one place, in the attribute definition, rather than cut
and pasted into every copy of every function that needs it.  In C / C++ you
have to use #define macros for this, which reduces the size of such copied
code, but doesn't eliminate the problem that it has to be copied in the
first place, (and subsequently maintained!).  These kind of user definable
attributes partially solve that problem, because you can declare
declarations in blocks to all be the same attribute.

Damn! It's getting late!  I better rein this in!

Sean



"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbk5c5l.4q6.jsykari pulu.hut.fi...
 In article <bhrn8p$251q$1 digitaldaemon.com>, Fabian Giesen wrote:
 People don't usually go around killing other people, firstly because
 [ ... ]

This is beside the point of what I'm trying to say. The question is why there is a compelling need for const. I only see an use for const if


 actual guarantee and the compiler can rely on it and act accordingly


 all const data into readonly segments, assume that anything declared


 is really constant for its whole lifetime).

Point taken. I didn't particularly try to advocate "const" as it is in C++, just wanted to point out that while it might play a role of a vague promise to the compiler, this is not the case for the programmer (and, importantly, maintainer), who enjoys the benefits of increased type information. I'm not sure if const is at all needed. Personally I've been a happy user of const ever since I learned C++ and haven't really tried to live without const (with the exception of occasional straying to the Java side). So I'd rather trust the opinions of the more experienced programmers. Meanwhile, let us concentrate for a moment on the meaning of const. Conceptually, the const as we know it in C++ offers a read-only access to the object. If we leave basic types and structs out of the picture, and just look at classes, we can implement it by separating the class' interface into read-only interface and the rest. If the class is already accessed via virtual functions (like a proper class should), this doesn't even impose any extra costs. "Const" access to the class can be provided by explicitly returning the read-only interface of the class, and this is in fact what happens when you specify a "const T" in C++: you actually get an object of type T, but can effectively access only the subset of member functions which are explicitly marked "const". This is also an issue that needs to be taken into consideration when designing the basic container library for D. Java, a blatant mockery of static typing, solves the "const" by providing a view to the container (via java.util.Collections.unmodifiableCollection or similar) which looks exactly like the original, but throws an UnsupportedOperationException when one tries to modify it. No wonder there's a project trying to bring "const" to Java (http://pag.lcs.mit.edu/constjava/). At any case, if the language has no const and someone wants non-writable containers, (and someone definitely will), the library designer must balance between proliferation of const interfaces and the risk of run-time errors. In C++ he could just leave the complication up to the language. Oh, and then there are the basic types which are left without any protection. But I suppose one can get away with some kind of boxing. And nobody wants to pass small values by const-qualified pointers anyway, so they are kind of non-issue. As a side note, "const" was originally proposed in 1981 and was called "readonly", and there was also "writeonly". (To mirror the properties of r/w bits in the memory controller; possibly memory-mapped hardware registers) The standardization process changed "readonly" to "const" and dropped "writeonly".
 As for const, that's a software design issue IMHO. If you add const,
 then make it rigid. Mutables are okay, because those are also part of
 the interface specification and thus also documented and acceptable.

So assume that we'd have these kind of strictly constant / rigidly constant / guaranteed to have the same value objects. "immutable" would not be a bad term, IMO, so I'll use it from now on. I can distantly see some consequences: - compiler could probably do some optimizations better - object of type T cannot be assigned to variable of type immutable T; to produce an immutable T you either have to clone it or have it be immutable from the beginning - there *will* be cases where the programmer wants to cast a T to immutable T because he simply knows that the object won't change. Should a simple cast like ((immutable T) t) suffice? - there would have to be methods with immutable modifier, which would comprise the immutable object's interface - plus the added complexity of overloading + other stuff that Walter has used as an argument against const All of this would complicate the language somewhat; but probably only after implementing and experimenting you would know whether it would be worth it. Are there any languages out there (except the purely functional ones) with immutable values? Now that I think of it, I remember that Daniel Yokomiso wrote an interesting description of const stuff some time ago, let's see... There, I see it's still worth reviewing: D/9962 (Daniel: how's Eon doing, by the way?) -Antti

Aug 20 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 I'm a heavy const user, a true believer in it, I'd say.  I'm going to

 out some ideas:

I'm also such an user of const...
 How about adding another kind of access specifier, starting with readonly,
 such that:

 class A
 {
     private T t;    // private data member
     readonly public:    // readonly section, also public.  this section
 applies to both rvalues and lvalues of class A
         T GetT() { return t; }
     readwrite:  // go back to readwrite, still public.  This section

 to lvalues
         this(in T t_) { t = t_; }
         T SetT(T other) { t = other; return this; }
 }

 A couple things I can see from the above:

 It adds complexity to initialization.  I recommend just ignoring all
 readonly accessors during a constructor, and maybe in the destructor too,

 in something obviously lvalue such as an assignment operator.

If something is read-only, IMO, assignment should be prohibited by default and if defined by the user, the user will be able only to assign to readwrite members...
 You can avoid having to constantly declare member functions const.  Just

 it in its own section.  This would save the "extra typing" overhead of C++
 const quite a bit.

I would even better like that when const is not specified that the function would be const candidate provide that it would have compiled if const was added. And we uses mutable to explictly tell that a member function is not const and cannot be used on const object even if it would have compiled if const was added. Note that for the return value, when a function is not decorated with a modifier the return value would become const if necessary (the compiler would also remember where const was implicitly added to display usefull error message to the user. Note that code that is compiled for a dynamic library, we should either always specify completly modifier (this would prevent accidental changes) or the compiler should remember the possibilities... Or we could have a keyword for automatic constness (autoconst) that would allows the compiler to decide...
 readonly and readwrite are a different set of attribute modifiers, totally
 separate from private public and protected.  Orthogonal to.  Unrelated.

 readonly sections can overlap public/private sections, or be overlapped by
 them.  readonly and readwrite might belong in the same category as


We could also have some more specifier that would be usefull (static, prohibited, published, exported, designtime, runtime, debug, final., inline, unline..) - static would make member static - prohibited would prevent uses (from everywhere - related to access) - published is public and visible by browsing tool (may be related to access) - exported would ensure the item is exported in a dynamic library (DLL) - designtime, runtime would indicate a property available for design or execution, - final would make methods non-virtual -...
 Public, private, protected control the visibility of names to everything
 outside the class.  readonly and readwrite control how the class sees

 (readonly interface, or readonly + readwrite interface) in those member
 functions, and controls assignability of fields.  in, out, and inout

 readwrite access to parameters of those functions, and const declares
 individual data rvalues, which aren't even castable to anything with write
 access.  That's a lot of names for one basic concept (readonly-ness), so
 perhaps it could all just be called const, or (lack of const) since the
 usage situation would already make it unambiguous what you meant.

 This readonly, for the builtin datatypes, and fundamentally, removes the
 ability to use the assignment operator on such values, or call anything

 that's a readwrite member function, on that type.   It should also prevent
 deletion or other forms of destruction/finalization.  And the compiler
 should be able to treat copies of such a value made during periods in

 it is sure are all protected by that attribute, that they remain identical
 so long as it knows the readonly attribute is attached to them.  When it
 becomes unsure, it could save and reload it to make sure any changes are
 reflected, but I'd rather guarantee that nothing will violate the
 constraint, ever, during the lifetime of the object or data.  The compiler
 should actively prevent the user from modifying such readonly values or
 allowing them to be modified whenever possible.  If that's too

 use something like mutable, which has different behavior in different
 situations.

In fact, using some more keywords (or attributes), we would be able to better control what we do... Some keywords that could be usefull are immuable, const, mutable, var(iable), compiletime, byref, byvalue,... Also, as mentionned in this thread, some modifier could be attributes... We would have a bunch of attributes that would give us more control when it is usefull...
 I would like to have a kind of constructor that basically allowed the

 to put whatever values they want into the class's fields, by name:

         this(in);   // how would you specify that you want the compiler to
 generate a method for you, without having to specify any body?
                         // By using prototype only, no body, kinda like

 It would generate a method for you regardless in C++, but this way you get
 to control the access.

 I'd use it like so:

 class Point
 {
     float x,y,z;
     this(in);  // allow construction with the caller being able to
 initialize the public fields and base class more or less directly

maybe, we should have a syntax like pure virtual function: this(in) = default;
     this(float x_, float y_, float z_) { x = x_, y = y_, z = z_; } //
 without that, you have to do this:
 }

 new Point a(x:1.0, y:2.0, z:0.0);   // call this(in) with initialization

 these members

And initialize other to default? If so, this could be nice...
 new Point a(1.0, 2.0, 0.0);   // initialize fields by calling
 this(float,float,float)

 or

 new Point a = { x:1.0; y:2.0, z:0.0 };  // same as this, which I think D
 allows now?  D does named field initialization, right?

Also what would be interesting is an uninitialized keyword so that we can created unitialized object explicitly when performance matters...
 Maybe structs just automatically work that way.

 And finally, like C#, I would like to be able to add my own attributes to
 things.  Groups of attributes (private/public/protected would be a group,
 and so would readonly/readwrite) declared sort of like enums.  Unlike
 anything I've heard of before, you should be able to alias and aggregate
 these attributes together (a global "alias private readonly
 notevenIcantouchit;" or "alias public mutable youcanlookbutyoucanttouch").
 If you could hook a couple prologue/epilog functions (inlined before and
 after every function body) to these attributes, then use them to control
 code generation the same way that contracts work now.

I really like this one too... and it would be even more interesting if some attributes can be different for debug/release, design/runtime,... so that for example, we can have debug functions that are not available in release version (for implementation, it might be a "pure virtual function called" when not available or something like that so that it would be easier to handled partial recompilations...
 Even better, you could use such attributes to *implement* things like
 contracts.

 Think about it.  What if you declared something akin to an in and out
 contract yourself?

 attribute in_custom in { print("in"); assert(this->good()); }
 attribute out_custom out { print("out"); assert(this->good()); }
 alias attribute in_custom out_custom invariant_custom;

 class Sign
 {
     invariant_custom:
         private int x;
         public this() { x = 0; }
         bit good() { return x >= 0 && x <= 10; }
         void badfunction() { ++x; badfunction(); } // will recurse 10

 and then trigger an assert exception!
 }

 The compiler would inject the attribute code into each function declared
 after it

 class Foo
 {
     attribute {
         my_read assign { assert(false && "don't assign to my_read objects,
 dumbass!"); }
         default my_readwrite { }
     };
         // everything up to this point is my_readwrite because it's the
 default!
     my_read int x; // if you try to assign this, you'll assert!
     my_readwrite:
         // everything else goes here
 }

I would then like to ba able to associate atributes also to classes and parameters... A great thing that may be possible is to implement a tracing facilities that would output all functions that are called with the value of their parameters.... I think this is possible with .NET... We just need to be able to get all parameters type and value...
 So there are a bunch of basic "kinds" of modifiers such as in, out,
 invariant, assign, destroy, copy, create, that sort of thing.  To control
 what situations the code attached to the attribute would apply in.    Also
 these attributes shouldn't run until the constructor for the object has
 finished, and shouldn't run once the finalizer starts.  That way it's
 guaranteed to have a complete object to deal with.

 I don't think it would be a good idea to allow decorating member variables
 with code.  Or would it?  A member variable or data attribute would

 things like assignment, reference, and might serve as an easy way to do
 properties with a write-through or read-only data field.  (The properties

 the D spec now may never see the light of day!)

 Maybe there should be some kind of compile time error for when the

 can detect at compile time that a code path is going to definitely be
 executed that contains an assert statement (such as the assign assert

 and issue a compile time error.

I would suggest a keyword (or predefined special function) that would be used instead of assert in such cases... And also one for functions that are not yet implemented or code that is not completed (todo, bug, ...) maybe compile_time_state(a) where a is an identifier and we can tell the compiler which identifier are ignored, which one causes a run-time error and which causes a compilation error.
 I guess all this adds to the complexity of the compiler.  That's a good
 thing, in some ways.  This could be powerful stuff in the right hands.
 Maybe could be combined with templates somehow?

I don't the relashion with template... but it may indeed be interesting to be able to do some metaprogramming based on those attributes.
 It's really just the ability to add custom extra type information to your
 types.

 One of the major costs of maintenance is having code cut-and-pasted in a
 bunch of places, as it is hard to change something if it's scattered all
 over the place.  With attributes you can write boilerplate code and attach
 it to things with an attribute in its declaration.  This is good because

 keeps such code in one place, in the attribute definition, rather than cut
 and pasted into every copy of every function that needs it.  In C / C++

 have to use #define macros for this, which reduces the size of such copied
 code, but doesn't eliminate the problem that it has to be copied in the
 first place, (and subsequently maintained!).  These kind of user definable
 attributes partially solve that problem, because you can declare
 declarations in blocks to all be the same attribute.

 Damn! It's getting late!  I better rein this in!

 Sean

I would like that the compiler would have a mode in which it case do some extended analysis of the code and potential pitfalls...
Aug 20 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bi0eoa$2uk4$1 digitaldaemon.com...
 It adds complexity to initialization.  I recommend just ignoring all
 readonly accessors during a constructor, and maybe in the destructor


 or in something obviously lvalue such as an assignment operator.

If something is read-only, IMO, assignment should be prohibited by default and if defined by the user, the user will be able only to assign to readwrite members...

Hmm. Anything that's not writable has to be initialized explicitly, which causes some order of construction issues, especially if field initializers reference other fields' values.
 You can avoid having to constantly declare member functions const.  Just

 it in its own section.  This would save the "extra typing" overhead of


 const quite a bit.

I would even better like that when const is not specified that the

 would be const candidate provide that it would have compiled if const
 was added. And we uses mutable to explictly tell that a member function
 is not const and cannot be used on const object even if it would have
 compiled if const was added.

This is just making it easier for people to be lazy. ;)
 Note that for the return value, when a function is not decorated with a
 modifier
 the return value would become const if necessary (the compiler would also
 remember where const was implicitly added to display usefull error message
 to the user.

It should be easy to add modifiers to a piece of data and hard/impossible to take them away (without making a new copy of the data/object)
 Note that code that is compiled for a dynamic library, we should either
 always specify completly modifier (this would prevent accidental changes)
 or the compiler should remember the possibilities...

I haven't thought it through that far. Not concerned with DLL's at this stage. ;)
 Or we could have a keyword for automatic constness (autoconst) that
 would allows the compiler to decide...

Hmm. People would forget the autoconst keyword. ;)
 We could also have some more specifier that would be usefull (static,
 prohibited, published, exported, designtime, runtime, debug, final.,

 unline..)

 - static would make member static
 - prohibited would prevent uses (from everywhere - related to access)
 - published is public and visible by browsing tool (may be related to
 access)
 - exported would ensure the item is exported in a dynamic library (DLL)
 - designtime, runtime would indicate a property available for design or
 execution,
 - final would make methods non-virtual
 -...

Sure, we could think of lots of predefined ones. It's talking Walter into them that's hard. ;)
 In fact, using some more keywords (or attributes), we would be able to
 better control what we do... Some keywords that could be usefull
 are immuable, const, mutable, var(iable), compiletime, byref, byvalue,...

People keep writing "immuable" when in fact the English word for that is "immutable". Dictionary.com says: No entry found for immuable. Did you mean immutable?
 Also, as mentionned in this thread, some modifier could be attributes...
 We would have a bunch of attributes that would give us more control
 when it is usefull...

People always want more control, and attributes would be so much better than command line switches. Makes the code self-documenting, self-directing, and removes the need for dealing with the compiler from the command line.
 class Point
 {
     float x,y,z;
     this(in);  // allow construction with the caller being able to
 initialize the public fields and base class more or less directly

maybe, we should have a syntax like pure virtual function: this(in) = default;

I never liked that syntax. I'd rather have the default in front, so it can be an attribute too!
 new Point a(x:1.0, y:2.0, z:0.0);   // call this(in) with initialization

 these members

And initialize other to default? If so, this could be nice...

Yes, unspecified fields would get their type's default, or whatever the class initializes them to by default.
 Also what would be interesting is an uninitialized keyword so that
 we can created unitialized object explicitly when performance
 matters...

Maybe you can't create uninitialized object that's derived from some other object (the bases will get initialized anyway) and if you call a constructor it has to get initialized. More of a declaration on a piece of data that says "I'm making a new object but don't want it initialized, and will not need to call any constructor". Basically just wraps allocation and typecasting. You could attribute member variables with this. Or any stack data. Maybe not classes.
 I really like this one too... and it would be even more interesting if
 some attributes can be different for debug/release, design/runtime,...
 so that for example, we can have debug functions that are not
 available in release version (for implementation, it might be a "pure
 virtual function called" when not available or something like that
 so that it would be easier to handled partial recompilations...

I never considered partial recompilation. Seems like everything that needs to be recompiled should be.
 I would then like to ba able to associate atributes also to classes
 and parameters...

Yes. To anything. Data, member functions, entire classes or structures or any type.
 A great thing that may be possible is to implement a tracing
 facilities that would output all functions that are called with
 the value of their parameters....

 I think this is possible with .NET... We just need to be able
 to get all parameters type and value...

That'd be handy sometimes.
 I would suggest a keyword (or predefined special function) that would be
 used instead of assert in such cases...

Good idea. Maybe a few variants on assert. assert is just shorthand for debug { if (x) throw AssertException; } Maybe one that throws a string message, or throws a message box to be executed... and one that throws nothing at all, just effectively a breakpoint. A debugger catches it and if there's no debugger, or in release builds, it just goes on past. That's something I always put in my libraries of code, a call to cause a breakpoint. Use that to build assert macros. Seems like a debugging feature (aka BASIC's stop command) which could be really useful.
 And also one for functions that are not yet implemented or code that is

 completed (todo, bug, ...)

Yeah, their code could print messages to the build log with line numbers etc.
 maybe compile_time_state(a) where a is an identifier and we can tell the
 compiler which identifier are ignored, which one causes a run-time error

 which causes a compilation error.

Switches like this are already handled with version statements; if we can define attributes differently depending on version, we're good to go.
 I guess all this adds to the complexity of the compiler.  That's a good
 thing, in some ways.  This could be powerful stuff in the right hands.
 Maybe could be combined with templates somehow?

I don't the relashion with template... but it may indeed be interesting to be able to do some metaprogramming based on those attributes.

I'm not sure. Haven't thought about that enough.
 I would like that the compiler would have a mode in which it case do some
 extended analysis of the code and potential pitfalls...

Pedantic. ;) lint mode. Sean
Aug 21 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 I would even better like that when const is not specified that the

 would be const candidate provide that it would have compiled if const
 was added. And we uses mutable to explictly tell that a member function
 is not const and cannot be used on const object even if it would have
 compiled if const was added.

This is just making it easier for people to be lazy. ;)

As mentionned in my other answer, you are right, it does not works well with virtual functions and since this is the default in D, the if someone can think not to forgot to make classes final when appropriate that people should be able be uses const as appropriate. So in pratice, constness modifier would be mostly usefull for libraries writers (similar to STL, boost and others...) but not that much for user. What do you think about allwing const only for final class type and simple types (integral, enum, struct, pointers) and not allows it on other types. And there would be a way to share code between a const and non-const version of the sane thing (constnessof would be a good keyword for that - it would allows to modifiy the constness of a type (including function return value) from the constness of another one or more)
Aug 23 2003
prev sibling next sibling parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.

----- Original Message -----
From: "Antti Sykäri" <jsykari gamma.hut.fi>
Newsgroups: D
Sent: Tuesday, August 19, 2003 8:14 PM
Subject: const / immutable (was: C++ style const concept)


[big snip]

 Now that I think of it, I remember that Daniel Yokomiso wrote an
 interesting description of const stuff some time ago, let's see...
 There, I see it's still worth reviewing:
 D/9962

Unfortunately my memory is not well lately and the newsgroup web interface seems to be down, so I talk something about this mutability issues. It's related to my pet language Eon.
 (Daniel: how's Eon doing, by the way?)

Eon is dead, long live Eon. Or something like that. The worst thing about designing a language is the pesky design decisions you have to make. I, after one year of study, dropped side-effects, and now Eon is a pure OOFPL. Here is the story of my attempts to provide immutability in the type-system. First some definitions: 1 - by side-effects I mean both observable and unobservable side-effects. 2 - I'll use procedures to describe methods with side-effects and functions to describe "pure", side-effect free, methods. 3 - mutable types are subtypes of immutable types, so we can call functions and procedures on mutable types and only functions on immutable types. 4 - a variable with an immutable type A holds a reference to some value of A, but this value can be mutated through other (mutable) references. My desire was to provide a way to verify, via static type checking, code correctness, specially regarding DbC. One of the most powerful contracts is the immutability contract, guaranteeing that some parameters of the operation will be untouched. int sum(immutable int[] array) { int result = 0; for (int i = 0; i < array.length; i++) { result += array[i]; } return result; } The "immutable" modifier indicates that the parameter won't be changed by the operation body. Notice that a immutable array of type T is distinct from a array of type immutable T; this "immutable" modifier refers to the array immutability, not the array element type immutability. This type modifier should be carried through assignment to avoid cheating, or else the operation could store the value in a mutable variable and break the immutability. There's a second way to use the "immutable" modifier: to define pure functions. int immutable product(immutable int[] array) { int result = 0; for (int i = 0; i < array.length; i++) { result *= array[i]; } return result; } An "immutable" operation won't cause side effects, so inside a class you can separate functions from procedures to ensure immutability. The compiler could enforce this rule disallowing procedure calls through immutable references. As soon as we define such rules we get in some problems: template TMin(T) { T immutable min(immutable T x, immutable T y) { return x < y ? x : y } } The min operation correctly asserts that it's parameters aren't mutated, but it incorrectly transform the immutable reference into a mutable one, using the "return". Here comes the first problem of immutability definitions: some operations return types depend on its parameter types. In these situations the return type mutability status is defined by the caller. Immutability depends heavily on the compiler, both to check the calls and to infer correctly the return type dependencies. There's also a third type of immutability: "immutable" types. But they're a beast of their own. In my language I decided to drop side-effects because: it's very expensive to track immutability and to provide two versions of the same operations (e.g. a put method that changes the collection and a put method that returns a new colection with the new value added). Also it'd very hard to write "ensure" clauses on method's contracts that have side-effects (google for "old" expression and clone in comp.lang.eiffel). Geting rid of side-effects allow the language and the libraries to become simpler, and we can simulate side-effects with linear types and monads. So, answering your question Antti, Eon is being rewritten by the last time. Today it's a pure OOFPL, with a higher-order features, a simple syntax to define object literals (i.e. "pair := {first := 1; second := "abcde"}"), predicate based multiple-inheritance (i.e. "class a := {x : Integer; y : Real and (> x) and odd};", we define x as an Integer and y as a Real number, greater than x and odd (odd and (> x) are predicates)). Unfortunately I had to restart the compiler (again) due to the syntatic and semantic changes. I believe this will be the last big change in the language and sometime in the next year (first semester probably) I'll have a working compiler and a standard library (collections, text, numerics, xml, io and networking) - most parts of the library are already specified (I have the method types and contracts and some implementations written in older versions of Eon).
 -Antti

Best regards, Daniel Yokomiso. "Nature has given us two ears but only one mouth." - Benjamin Disraeli (1804-81), British politician --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003
Aug 24 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <biafl2$2tsa$1 digitaldaemon.com>, Daniel Yokomiso wrote:
     Eon is dead, long live Eon. Or something like that. The worst thing
 about designing a language is the pesky design decisions you have to make.
 I, after one year of study, dropped side-effects, and now Eon is a pure
 OOFPL. Here is the story of my attempts to provide immutability in the
 type-system. First some definitions:
 
 1 - by side-effects I mean both observable and unobservable side-effects.
 2 - I'll use procedures to describe methods with side-effects and functions
 to describe "pure", side-effect free, methods.
 3 - mutable types are subtypes of immutable types, so we can call functions
 and procedures on mutable types and only functions on immutable types.
 4 - a variable with an immutable type A holds a reference to some value of
 A, but this value can be mutated through other (mutable) references.

So this would be equivalent to C++'s const. (Without the possibility of subverting the type system, though.) I'll blabber a bit more about immutability below.
 int sum(immutable int[] array) {
     int result = 0;
     for (int i = 0; i < array.length; i++) {
         result += array[i];
     }
     return result;
 }
 
 
     The "immutable" modifier indicates that the parameter won't be changed
 by the operation body. Notice that a immutable array of type T is distinct
 from a array of type immutable T; this "immutable" modifier refers to the
 array immutability, not the array element type immutability. This type

One interesting question regarding the semantics of immutable here is that what is the difference between immutable array of int and array of immutable int. Because the array can be viewed as consisting of its elements, doesn't its immutability imply the immutability of its elements and therefore make it equivalent to immutable array of immutable integers? It seems to depend on the kind of array and of the kind of the language it lives in. I'd assume (in pseudo-code notation) that array in a very "pure" modern, orthogonal, clean, type-safe etc. language (I'm putting some expectations on Eon you see after all those papers you've read :-) would have operations like: class immutable_array<T> { T get(int); // return by-value copy of element at i int length(); } class array<T> extends immutable_array<T> { void set(T, int) // set value at T to int void length(int); } This would mean in practice that having an immutable array would prohibit changing its elements, which would render them practically immutable. On the other hand, if the hypothetical language were less clean and had something as down-and-dirty as aliasing and references, what would an array then look like? Like this?: array<T> { T& get(int); // return a reference to element at i // other properties } Now what would the "immutable part of the interface" look like? Would it have the function "immutable T& get(int)"? But this would have the same signature, except for the hidden argument that contains the reference to the object the method is part of. Ah, there's the catch: immutable_array<T> { immutable T& immutable get(int); // other properties } And lo, we get C++ rules along with all the special cases and all. (There probably is some kind of logic to them after all, especially if you remove the warts induced by the C compatibility.) If you have by-reference object, say of type T, what does "immutable T" mean? That you cannot change the reference to point to another object? Or that you can call only the pure methods of the object? Are the rules different if you have value objects?
 modifier should be carried through assignment to avoid cheating, or else the
 operation could store the value in a mutable variable and break the
 immutability. There's a second way to use the "immutable" modifier: to
 define pure functions.

At this phase I must point out that the semantics seem awfully familiar from C++, only the names differ: method - member function immutable - const pure function - const member function
     An "immutable" operation won't cause side effects, so inside a class you
 can separate functions from procedures to ensure immutability. The compiler
 could enforce this rule disallowing procedure calls through immutable
 references. As soon as we define such rules we get in some problems:
 
 
 template TMin(T) {
     T immutable min(immutable T x, immutable T y) {
         return x < y ? x : y
     }
 }

Why not: template TMin(T) { immutable T immutable min(immutable T x, immutable T y) { return x < y ? x : y; } } I'd assume it would be instantiated automatically. It would of course need along the normal version: template TMin(T) { T min(T x, T y) { return x < y ? x : y; } } And the overloading rules to pick the right version.
     In my language I decided to drop side-effects because: it's very
 expensive to track immutability and to provide two versions of the same
 operations (e.g. a put method that changes the collection and a put method
 that returns a new colection with the new value added). Also it'd very hard

I'd assume that you wouldn't need two versions; if you only want to have an immutable and a mutable version of a class, just drop the procedures and leave the pure methods in the immutable version -- calling the procedure on the immutable version would be prohibited at compile time, nice and clean. Maybe you wanted something completely different?
 Also it'd very hard to write "ensure" clauses on method's contracts
 that have side-effects (google for "old" expression and clone in
 comp.lang.eiffel).

Shouldn't "ensure" clauses *not* have side-effects? Or did you mean "ensure" clauses of methods that have side-effects? Uh, could you give an example of one hard case? The thread you pointed at is probably the one with the subject "'old' + 'implies' = bug ?" (from 1996)? An interesting thread. "old" is a funny modifier, but one wonders if the semantical trouble arised because its real semantics ("will be evaluated before entering the function although it is mentioned and used only at the end") was swept under the rug while humming noble tunes about mathematical theories about contracts. And of course all the expressions in contracts are side-effectsless, at least if we don't cheat, right? *grin* IMHO all things that go with contracts tend to be a bit flaky. I just read (OOSC 2nd ed.) about abstract contracts that make it possible to actually tighten the preconditions in a deriving class, which shouldn't be possible -- but in this case is. (See the example about BOUNDED_STACK in the chapter about inheritance techniques.) I've not finished studying Eiffel's contract system in full but I do have the feeling that it's designed with a bit too much theory in mind -- I'd rather concentrate in making the constructs as usable and transparent as possible than create overly complicated (or overly simplified) theories and then watch them break in normal practical situations.
     So, answering your question Antti, Eon is being rewritten by the last
 time. Today it's a pure OOFPL, with a higher-order features, a simple syntax

 standard library (collections, text, numerics, xml, io and networking) -
 most parts of the library are already specified (I have the method types and
 contracts and some implementations written in older versions of Eon).

Best of luck with Eon, the type system pretty looks interesting. Must be worth the intellectual exercise, at least. (I must confess that I don't put much value on purely functional languages, but that could be just because I haven't studied them enough. Perhaps I shall be enlightened one day and write only Haskell after that.) To conclude, it seems that the efforts to combine mutable and immutable values tend to divert in different directions. Some (D) make the language simpler by forgetting constant types (almost) altogether. Some (Eon) go to the other extreme and make everything purely functional. Some (C++) march bravely forth and allow the complexity caused by having both the constant and the mutable. This makes wonder if there is at all a simple and beautiful language that would at the same time allow the constant and non-constant types to live peacefully together... -A
Aug 25 2003
parent reply "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
Hi,

    Comments embedded.

----- Original Message -----
From: "Antti Sykäri" <jsykari gamma.hut.fi>
Newsgroups: D
Sent: Monday, August 25, 2003 9:07 PM
Subject: Re: const / immutable (was: C++ style const concept)

[snip]

 So this would be equivalent to C++'s const. (Without the possibility of
 subverting the type system, though.)

 I'll blabber a bit more about immutability below.

 int sum(immutable int[] array) {
     int result = 0;
     for (int i = 0; i < array.length; i++) {
         result += array[i];
     }
     return result;
 }


     The "immutable" modifier indicates that the parameter won't be


 by the operation body. Notice that a immutable array of type T is


 from a array of type immutable T; this "immutable" modifier refers to


 array immutability, not the array element type immutability. This type

One interesting question regarding the semantics of immutable here is that what is the difference between immutable array of int and array of immutable int. Because the array can be viewed as consisting of its elements, doesn't its immutability imply the immutability of its elements and therefore make it equivalent to immutable array of immutable integers?

If you have (using const to mark immutability): class Cell { private int value; this(int value) { this.value = value; } public void set(int value) { this.value = value; } public int immutable get() { return this.value; } } Cell c0 = new Cell(0), c1 = new Cell(1), c2 = new Cell(2), c3 = new Cell(3); Cell[] a0 = [c1, c2, c3]; // mutable array of mutable cell references immutable Cell[] a1 = [c1, c2, c3]; // mutable array of immutable cell references Cell[immutable] a2 = [c1, c2, c3]; // immutable array of mutable cell references const Cell[immutable] a3 = [c1, c2, c3]; // immutable array of immutable cell references a0[0].set(0); // ok, the a0[0] reference isn't immutable a0[0] = c2; // ok, the array isn't immutable a1[0].set(0); // compiler error, the a1[0] reference is immutable a1[0] = c2; // ok, a1 isn't immutable a2[0].set(0); // ok, the a2[0] reference isn't immutable a2[0] = c2; // compiler error, a2 is immutable a3[0].set(0); // compiler error, the a1[0] reference is immutable a3[0] = c2; // compiler error, a3 array is immutable Therefore I think that separating the immutability issue of the array vs. the element type leads to different semantics. Here we assume that "immutable A" is a supertype of "A".
 It seems to depend on the kind of array and of the kind of the language
 it lives in.

 I'd assume (in pseudo-code notation) that array in a very "pure" modern,
 orthogonal, clean, type-safe etc. language (I'm putting some
 expectations on Eon you see after all those papers you've read :-) would
 have operations like:

 class immutable_array<T>
 {
     T get(int); // return by-value copy of element at i
     int length();
 }

 class array<T> extends immutable_array<T>
 {
     void set(T, int) // set value at T to int
     void length(int);
 }

 This would mean in practice that having an immutable array would
 prohibit changing its elements, which would render them practically
 immutable.

Immutable operations ("T immutable get(int)" and "int immutable length()") won't have side effects, but they may be changed by other objects/threads. But if you have a value type (like a number, matrix, etc.), a immutable struct type, you'll be safe, because the value isn't shared. Immutability tell us nothing about aliasing.
 On the other hand, if the hypothetical language were less clean and had
 something as down-and-dirty as aliasing and references, what would an
 array then look like? Like this?:

 array<T>
 {
     T& get(int); // return a reference to element at i
     // other properties
 }

 Now what would the "immutable part of the interface" look like? Would it
 have the function "immutable T& get(int)"? But this would have the same
 signature, except for the hidden argument that contains the reference to
 the object the method is part of. Ah, there's the catch:

 immutable_array<T>
 {
     immutable T& immutable get(int);
     // other properties
 }

 And lo, we get C++ rules along with all the special cases and all.
 (There probably is some kind of logic to them after all, especially if
 you remove the warts induced by the C compatibility.)

The problem in C++ is that they use "a[0] = 1;" meaning, get the address of the first element and let it be assignable, so you need two versions of array_get, one yielding const references and other yielding normal ones. IMO "a[0]" should call array_get and "a[0] = 1" should call array_set, just syntatic sugar.
 If you have by-reference object, say of type T, what does "immutable T"
 mean?  That you cannot change the reference to point to another object?
 Or that you can call only the pure methods of the object? Are the rules
 different if you have value objects?

array<T> { T const get(int); int const length(); void set(int,T); void length(int); } int i1 = 1, i2 = 2, i3 = 3, i4 = 4; array<int> a1 = [i1, i2, i3, i4]; array<&int> a2 = [i1, i2, i3, i4]; const array<int> a3 = [i1, i2, i3, i4]; const array<&int> a4 = [i1, i2, i3, i4]; const array<const &int> a5 = [i1, i2, i3, i4]; a1.set(0, i3); // ok a2.set(0, &i3); // ok a2.get(0) = 5; // ok a3.set(0, i3); // compiler error a4.set(0, &i3); // compiler error, can't mutate the array. a4.get(0) = 8; // ok a5.set(0, &i3); // compiler error a5.get(0) = 8; // compiler error It's a bit tricky, but the const qualifies the reference type too.
 modifier should be carried through assignment to avoid cheating, or else


 operation could store the value in a mutable variable and break the
 immutability. There's a second way to use the "immutable" modifier: to
 define pure functions.

At this phase I must point out that the semantics seem awfully familiar from C++, only the names differ: method - member function immutable - const pure function - const member function
     An "immutable" operation won't cause side effects, so inside a class


 can separate functions from procedures to ensure immutability. The


 could enforce this rule disallowing procedure calls through immutable
 references. As soon as we define such rules we get in some problems:


 template TMin(T) {
     T immutable min(immutable T x, immutable T y) {
         return x < y ? x : y
     }
 }

Why not: template TMin(T) { immutable T immutable min(immutable T x, immutable T y) { return x < y ? x : y; } } I'd assume it would be instantiated automatically. It would of course need along the normal version: template TMin(T) { T min(T x, T y) { return x < y ? x : y; } } And the overloading rules to pick the right version.

Hmmm, perhaps you've meant: template TMin(T) and template TMin(immutable T) But the issue here is that immutability, when you're dealing with generic types, generates some dependency between the parameters and the result types. Sometimes only one parameter will define the const issue, sometimes more than one. If you make a templated function to find statistical results from a array (min, max, average, etc.) you need a way to ensure that these functions won't: mutate the array, won't mutate the array elements, the return types will have the same immutability status (yes or no) that the array element type. In your example the TMin version for mutable parameters allowed the min function to change them through any mutating methods they had.
     In my language I decided to drop side-effects because: it's very
 expensive to track immutability and to provide two versions of the same
 operations (e.g. a put method that changes the collection and a put


 that returns a new colection with the new value added). Also it'd very


 I'd assume that you wouldn't need two versions; if you only want to have
 an immutable and a mutable version of a class, just drop the procedures
 and leave the pure methods in the immutable version -- calling the
 procedure on the immutable version would be prohibited at compile time,
 nice and clean.

 Maybe you wanted something completely different?

I was talking about the issue I mentioned in my last (statistical) example. You need to write things like: template stats(T) { const_if_array_type_is_const T find_min(const T [const] array) { ... } } That can be very awkward. The problem here is: the result type immutability depends on the array element type immutability, but we must be able to ensure that the array element type won't be changed by the function. These examples may be simple, but when you have more classes, it's hard to track immutability dependencies. Also immutability is one level only: class Cell(T) { private T value; this(T value) { this.value = value; } public void set(T value) { this.value = value; } public T immutable get() { return this.value; } } Cell(int) c1 = new Cell(int)(1); const Cell(Cell(int)) c2 = new Cell(Cell(int))(c1); const Cell(const Cell(Cell(int))) c3 = new Cell(const Cell(Cell(int)))(c2); c3.set(c2); // compiler error; c3.get().set(c1); // compiler error; c3.get().get().set(0); // ok; With "Cell" classes it's easy, because you can specify the internal elements immutability status, but some classes, like "Department" that contains "Employee", are harder, because you may mutate "Employee" through a "immutable Department" reference, because you must be able to tell that the "Employee get(String)" won't mutate the "Department", but when called via a "immutable Deparment" reference should yield a "immutable Employee", but when calles via a common "Department" reference should yield a common "Employee". If we include the implicit this parameter in the type we may be able to do this (somehow, but's awkward): immutable Employee immutable get(immutable Department this, immutable String name); Employee immutable get(Department this, immutable String, name); where the "immutable" qualifier before the "get" means the this reference won't be mutated. Some issues regarding mutability are discussed here <http://lambda.weblogs.com/discuss/msgReader$8378?mode=topic&y=2003&m=8&d=25
 Tim Sweeney has some pretty good thoughts.

 Also it'd very hard to write "ensure" clauses on method's contracts
 that have side-effects (google for "old" expression and clone in
 comp.lang.eiffel).

Shouldn't "ensure" clauses *not* have side-effects? Or did you mean "ensure" clauses of methods that have side-effects? Uh, could you give an example of one hard case?

Sorry I meant: 'Also it's very hard to write "ensure" clauses on contracts of methods that have side-effects (i.e. methods that mutate the instance)'. Set(T) { void remove(T item) out () { if (old this.contains(item)) { assert(this.size + 1 == (old this.size())); } assert(!this.contains(item)); // so far so good. for (T each; old this) { if (each != item) { assert(this.contains(item)); } } /* ops, it won't work because the "old this" expression will yield a reference * to the this object, and here it's already mutated. The correct expression is * "(old this.clone())" ensuring that we get a snapshot of the this object from * before the method execution. */ }; } This is the simplest case of "old" expressions in mutating methods. There's more fun. Check the Eiffel kernel classes' contracts for more details. [snip]
     So, answering your question Antti, Eon is being rewritten by the


 time. Today it's a pure OOFPL, with a higher-order features, a simple


 [snip]
 standard library (collections, text, numerics, xml, io and networking) -
 most parts of the library are already specified (I have the method types


 contracts and some implementations written in older versions of Eon).

Best of luck with Eon, the type system pretty looks interesting. Must be worth the intellectual exercise, at least. (I must confess that I don't put much value on purely functional languages, but that could be just because I haven't studied them enough. Perhaps I shall be enlightened one day and write only Haskell after that.) To conclude, it seems that the efforts to combine mutable and immutable values tend to divert in different directions. Some (D) make the language simpler by forgetting constant types (almost) altogether. Some (Eon) go to the other extreme and make everything purely functional. Some (C++) march bravely forth and allow the complexity caused by having both the constant and the mutable. This makes wonder if there is at all a simple and beautiful language that would at the same time allow the constant and non-constant types to live peacefully together... -A

As I (hopefully) showed you, the immutability issue is very tricky. Once we assume that everything can mutate we need to state everything that won't change everytime. There are lots of hard work on this area, some propose a "mutates" clause on methods, to define which object's parts will be different after a method call. My test of Eon features was writing libraries with the proposed syntax and semantics. When Eon had side-effects as the norm and keywords to ensure immutability the code become very, very verbose. Once I dropped the side-effects, I could concentrate on behaviour and isolate the changes in Monads. IME it's almost impossible to come with a readable, concise and comprehensive notation for immutability vs. mutability. Best regards, Daniel Yokomiso. "I didn't attend the funeral, but I sent a nice letter saying I approved of it." - Mark Twain --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 20/8/2003
Aug 26 2003
next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bifhh6$1hb7$1 digitaldaemon.com...
     Therefore I think that separating the immutability issue of the array
 vs. the element type leads to different semantics. Here we assume that
 "immutable A" is a supertype of "A".

This seems logical.
     Immutable operations ("T immutable get(int)" and "int immutable
 length()") won't have side effects, but they may be changed by other
 objects/threads. But if you have a value type (like a number, matrix,

 a immutable struct type, you'll be safe, because the value isn't shared.
 Immutability tell us nothing about aliasing.

Not having side effects allows one set of optimizations. I would like the language to include something like "values changed by other threads *can* show up as changed to a thread which uses those values, however, changes are not *guaranteed* to show up unless the values are marked volatile." This would allow the compiler to keep more values in registers. Not sure what to do about called functions. There is something extremely nice about knowing for sure that nothing will ever modify a structure.
     The problem in C++ is that they use "a[0] = 1;" meaning, get the

 of the first element and let it be assignable, so you need two versions of
 array_get, one yielding const references and other yielding normal ones.

 "a[0]" should call array_get and "a[0] = 1" should call array_set, just
 syntatic sugar.

Basically properties.
     But the issue here is that immutability, when you're dealing with
 generic types, generates some dependency between the parameters and the
 result types. Sometimes only one parameter will define the const issue,
 sometimes more than one. If you make a templated function to find
 statistical results from a array (min, max, average, etc.) you need a way

 ensure that these functions won't: mutate the array, won't mutate the

 elements, the return types will have the same immutability status (yes or
 no) that the array element type. In your example the TMin version for
 mutable parameters allowed the min function to change them through any
 mutating methods they had.

This is what I don't understand. Why should Min return an immutable value? Perhaps it can return a copy of a value that can be mutated. That's probably lower performance though. Is this the only reason? Sean
Aug 26 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
----- Original Message -----
From: "Sean L. Palmer" <palmer.sean verizon.net>
Newsgroups: D
Sent: Tuesday, August 26, 2003 12:27 PM
Subject: Re: const / immutable [long]


 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bifhh6$1hb7$1 digitaldaemon.com...

[snip]
     But the issue here is that immutability, when you're dealing with
 generic types, generates some dependency between the parameters and the
 result types. Sometimes only one parameter will define the const issue,
 sometimes more than one. If you make a templated function to find
 statistical results from a array (min, max, average, etc.) you need a


 to
 ensure that these functions won't: mutate the array, won't mutate the

 elements, the return types will have the same immutability status (yes


 no) that the array element type. In your example the TMin version for
 mutable parameters allowed the min function to change them through any
 mutating methods they had.

This is what I don't understand. Why should Min return an immutable

 Perhaps it can return a copy of a value that can be mutated.  That's
 probably lower performance though.  Is this the only reason?

Here's an example that illustrates this. class Cell { private int value; public this(int _value) { this.value = _value; } public int immutable get() { return this.value; } public void set(int _value) { this.value = _value; } } template TPair(T, U) { class Pair { private final T first; private final U second; public this(T _first, U _second) { this.first = _first; this.second = _second; } public T immutable first() { return this.first; } public T immutable second() { return this.second; } } } alias instance TPair(Cell, Cell) CellPair; alias instance TPair(immutable Cell, immutable Cell) ImmutableCellPair; ImmutableCellPair minMax(immutable Cell[immutable] array) in { assert(array.length > 0); } body { immutable Cell min = array[0], max = array[0]; // must be immutable for (int i = 1; i < array.length; i++) { if (array[i].get() < min.get()) { min = array[i]; } else if (array[i].get() > max.get()) { max = array[i]; } } return new ImmutableCellPair(min, max); // must be immutable } int main() { Cell[] array = [new Cell(1), new Cell(2), new Cell(3)]; CellPair pair = minMax(array); // compiler error pair.first().set(0); pair.second().set(1000); return 0; } Inside "minMax" we only have immutable references, so we must construct a template to a "immutable Cell". Inside "main" we can access the array elements as mutable references, but the result of the "minMax" function is immutable, even if we are the "owners" of the object. That's the trick, a way to define a function interface, specifying that it won't mutate the parameters, but allowing the result immutability to depend upon the parameter's mutability. Sometimes the result immutability depends on all parameters, sometimes just on some of them, or even on none of them. Another interesting example. class Box : Cell { public this(int _value) { super(_value); } public Box self() { return this; } } int main() { Box b1 = new Box(1); immutable Box b2 = new Box(2); // the following statement require that "self" return a immutable Box. printf("%d\r\n", b2.self().get()); // but if it's immutable the following code doesn't work b1.self().set(2); printf("%d\r\n", b1.self().get()); return 0; } The "self" method needs to be mutable when called through mutable interfaces and immutable when called through immutable interfaces. It's just a harmless method ;)
 Sean

--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003
Aug 26 2003
prev sibling next sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
     But the issue here is that immutability, when you're dealing with
 generic types, generates some dependency between the parameters and the
 result types. Sometimes only one parameter will define the const issue,
 sometimes more than one. If you make a templated function to find
 statistical results from a array (min, max, average, etc.) you need a way

 ensure that these functions won't: mutate the array, won't mutate the

 elements, the return types will have the same immutability status (yes or
 no) that the array element type. In your example the TMin version for
 mutable parameters allowed the min function to change them through any
 mutating methods they had.


     In my language I decided to drop side-effects because: it's very
 expensive to track immutability and to provide two versions of the



 operations (e.g. a put method that changes the collection and a put


 that returns a new colection with the new value added). Also it'd very


 I'd assume that you wouldn't need two versions; if you only want to have
 an immutable and a mutable version of a class, just drop the procedures
 and leave the pure methods in the immutable version -- calling the
 procedure on the immutable version would be prohibited at compile time,
 nice and clean.

 Maybe you wanted something completely different?

I was talking about the issue I mentioned in my last (statistical) example. You need to write things like: template stats(T) { const_if_array_type_is_const T find_min(const T [const] array) { ... } } That can be very awkward. The problem here is: the result type immutability depends on the array element type immutability, but we must

 able to ensure that the array element type won't be changed by the

 These examples may be simple, but when you have more classes, it's hard to
 track immutability dependencies. Also immutability is one level only:

maybe something like that would be OK: template stats(T) { constnessof(array) T find_min(const T [const] array) } where we can indicate what to check for constness. The list can include this for member functions and for complex type we might allows a syntax similar to the one used for specialisation constnessof(array : pattern) where patern would include the optional const or alternatively a syntax where we could name modifier: For the sample I will uses # symbol. There are probably better alternative. Makes your suggestions!!! template stats(T) { constnessof(c1, c2) T find_min(const#c1 T [const#c2] array) } For non-virtual methods, we could support automatic constness detection which should not be hard for the compiler to implement (about the same complexity as generating an error in C++ when constness is not respected). template stats(T) { autoconst T find_min(const T [const] array) } where const would be added if required. This would be usefull for generic code like the TMin template or for containers that wants to return constant reference to their elements if they are themself const... Automatic modifier would also have other uses that for constness support. They would be usefull for function calling convention for example (I don't know how those specifier are handled in D - that is the equivalent of cdecl, fastcall, pascal and similar in C++). For ex. in C++, mem_fun and related classes and functions only works when the default calling convention is used... but ideally the same code should be usable with any calling convention.
Aug 26 2003
parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Philippe Mori" <philippe_mori hotmail.com> escreveu na mensagem
news:big4ek$2e9p$1 digitaldaemon.com...

[snip]

 maybe something like that would be OK:

 template stats(T)
 {
     constnessof(array) T find_min(const T [const] array)
 }

 where we can indicate what to check for constness. The
 list can include this for member functions and for complex type
 we might allows a syntax similar to the one used for specialisation

     constnessof(array : pattern)

 where patern would include the optional const

 or alternatively a syntax where we could name modifier: For the
 sample I will uses # symbol. There are probably better alternative.
 Makes your suggestions!!!

 template stats(T)
 {
     constnessof(c1, c2) T find_min(const#c1 T [const#c2] array)
 }

 For non-virtual methods, we could support automatic constness
 detection which should not be hard for the compiler to implement
 (about the same complexity as generating an error in C++ when
 constness is not respected).

 template stats(T)
 {
     autoconst T find_min(const T [const] array)
 }

 where const would be added if required.

 This would be usefull for generic code like the TMin template
 or for containers that wants to return constant reference to their
 elements if they are themself const...


 Automatic modifier would also have other uses that for constness
 support. They would be usefull for function calling convention for
 example (I don't know how those specifier are handled in D - that
 is the equivalent of cdecl, fastcall, pascal and similar in C++).

 For ex. in C++, mem_fun and related classes and functions only
 works when the default calling convention is used... but ideally
 the same code should be usable with any calling convention.

Yes, this "constnessof" and "autoconst" would solve the issues I was talking about. I think they might open new cans of worms, but there's another issue. In Eon I started doing something like that, later generalizing the idea of dependent mutability to dependent typing, which is just a few steps ahead, but improves the expressiveness by an order of magnitude. "Philippe Mori" <philippe_mori hotmail.com> escreveu na mensagem news:big4ek$2e9p$1 digitaldaemon.com... [snip]
 maybe something like that would be OK:

 template stats(T)
 {
     constnessof(array) T find_min(const T [const] array)
 }

 where we can indicate what to check for constness. The
 list can include this for member functions and for complex type
 we might allows a syntax similar to the one used for specialisation

     constnessof(array : pattern)

 where patern would include the optional const

 or alternatively a syntax where we could name modifier: For the
 sample I will uses # symbol. There are probably better alternative.
 Makes your suggestions!!!

 template stats(T)
 {
     constnessof(c1, c2) T find_min(const#c1 T [const#c2] array)
 }

 For non-virtual methods, we could support automatic constness
 detection which should not be hard for the compiler to implement
 (about the same complexity as generating an error in C++ when
 constness is not respected).

 template stats(T)
 {
     autoconst T find_min(const T [const] array)
 }

 where const would be added if required.

 This would be usefull for generic code like the TMin template
 or for containers that wants to return constant reference to their
 elements if they are themself const...


 Automatic modifier would also have other uses that for constness
 support. They would be usefull for function calling convention for
 example (I don't know how those specifier are handled in D - that
 is the equivalent of cdecl, fastcall, pascal and similar in C++).

 For ex. in C++, mem_fun and related classes and functions only
 works when the default calling convention is used... but ideally
 the same code should be usable with any calling convention.

Yes, this "constnessof" and "autoconst" would solve the issues I was talking about. I think they might open new cans of worms, but there's another issue. In Eon I started doing something like that, later generalizing the idea of dependent mutability to dependent typing, which is just a few steps ahead, but improves the expressiveness by an order of magnitude.
Aug 26 2003
prev sibling parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
Ok, let's drop immutable and just talk about const.

In article <bifhh6$1hb7$1 digitaldaemon.com>, Daniel Yokomiso wrote:
     But the issue here is that immutability, when you're dealing with
 generic types, generates some dependency between the parameters and the
 result types. Sometimes only one parameter will define the const issue,
 sometimes more than one. If you make a templated function to find
 statistical results from a array (min, max, average, etc.) you need a way to
 ensure that these functions won't: mutate the array, won't mutate the array
 elements, the return types will have the same immutability status (yes or
 no) that the array element type. In your example the TMin version for
 mutable parameters allowed the min function to change them through any
 mutating methods they had.
 

[snip]
 Maybe you wanted something completely different?

I was talking about the issue I mentioned in my last (statistical) example. You need to write things like: template stats(T) { const_if_array_type_is_const T find_min(const T [const] array) { ... } } That can be very awkward. The problem here is: the result type immutability depends on the array element type immutability, but we must be able to ensure that the array element type won't be changed by the function.

Okay, now I think I have an idea about the fundamental problem. The min() function can be used as an example of the general idea. The function must return one of its arguments, whether mutable or immutable. At the same time it must provide the guarantee that it won't modify its arguments -- we'd like the type system to ensure that the only thing that "min(T, T)" is allowed to do is to pass one of its arguments back to the caller. One way to ensure this is to make its arguments const; but then you'd have to make its return type const, as well, or the following wouldn't compile: (Let's leave the bodies away -- everybody probably knows what "min" looks like if he or she has read this far :) I'll drop the template syntax because it has nothing to do with const really. Assume that T is an int or actually, reference type would be better to illustrate the const semantics. const T min(const T x, const T y); This is inacceptable, because sometimes we'd like to use min on non-const arguments; therefore we could solve the problem with overloading: T min(T x, T y); const T min(const T x, const T y); And we need to have C++-like rules to disambiguate between the calls, or maybe now we could have some use for templates: implicit template function (const T) { const T min(const T x, const T y); } implicit template function (T) { T min(T x, T y); } Another way would be unsafe and dirty but I'll still include it for completeness: T min(const T x, const T y) { T mutable_x = const_cast<T>(x), mutable_y = const_cast<T>(y); return x < y ? mutable_x : mutable_y; } However, this would require the caller to promise not to touch the result if one of the originals were const in the first place. Ok, pretty ugly idea but its actually a prelude to this solution: Don't use "const" as a type modifier at all, but merely as a way of documenting the function's behavior (as in "I won't change this parameter"). Enter contracts. Like so: T min(const T x, const T y) { // implementation... } out() { // mathematical properties of min(x,y) assert(result <= x); assert(result <= y); // it's one of them assert(result === x || result === y); // I didn't change my parameters, I promise; these would be // generated by "const" assert(old x == x); assert(old y == y); // Here we would actually have to rely on // deep_clone or similar, as you mentioned below. Tricky notion, // comparing something that exists now to something that existed // earlier in time } Side note: Don't you just love when the function's postconditions actually describe perfectly what the function does! Reminds of me of the good old combinator function in purely functional languages. It takes a function of type ('a -> 'b) and a function of type ('b -> 'c) and returns a function of type ('a -> 'c). Now what could a function of this type do? The notation "'something" means generic type parameter, so it cannot assume anything about its types. Well, what else can it do, then, than create a function that first calls the first function and then calls the second function on the result? So the function's type is a complete description of the function itself. Back to the min() problem. Ideas only keep getting wilder... well, do you remember how we did it in C times: Macro! Of course! #define min(x, y) ((x) < (y) ? (x) : (y)) This actually works better (except for the side-effects of call-by-name parameter passing) than any of its C++ equivalents, since you can do things like int x = 5; const float y = 1.0; float z = min(x, y); No need for different "const" methods, overloading or anything! Amazing! Compare this with what Andrei Alexandrescu did to get the (nearly) similar effect with templates: http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/ By the way, he has an interesting comment: "Minimum and maximum are two simple concepts present both in math and in the real life. If a programming language is unable to express simple concepts of math and life, then there is something deeply wrong with that language." Anyway - macros seem to work. Why is this possible? Well, because min() is not an actual function call but merely a textual substitution. Well, what language feature was introduced in C++ (and later, in C) to get rid of a certain usage of macros? Taking Andrei's challenge, let's bring forth the final solution: inline functions. I wouldn't mean to use inline functions as a means to perform premature optimization, a purpose which programmers are often accused of misusing. But I simply would want to take advantage of the fact that inline functions can "see" the context where they are used, and therefore they would also be able to provide different kinds of code than usual functions. Actually, after an inline function were expanded several times, the compiler could gather them to a single (if possible) function and optimize the inlined code to a function call :) One thing that inline functions could provide would be determining the return type based on argument types. In fact, the inline function could work directly on the symbolic environment of the caller; assume inline Symbol min(Symbol x, Symbol y) { return x < y ? x : y; } This would expand similarly to the macro: void g(int x, float y) { float z = min(x, y); // expands into: // float z = x < y ? x : y; } It would have to have different specialisations; for non-symbol expressions, the following would be expanded: inline T min(T x, T y) { // as usual } Inline functions would of course have to have some kind of template-like implicit instantiation mechanism (which D templates is soon going to get, I hope) and ability to specialize on different types. And they could naturally be used to implement variable-sized argument lists type-safely... Hmm, I think I got sidetracked a bit. Could be time for sleep.
      Some issues regarding mutability are discussed here
<http://lambda.weblogs.com/discuss/msgReader$8378?mode=topic&y=2003&m=8&d=25
 Tim Sweeney has some pretty good thoughts.


An interesting discussion. BTW, the guy who he was talking with, Vesa Karvonen, I used to work with some time ago. He's a smart guy; taught me a lot about programming. It's a small world, and particularly small in the area of functional languages and type theory :)
 Uh, could you give an example of one hard case?

Sorry I meant: 'Also it's very hard to write "ensure" clauses on contracts of methods that have side-effects (i.e. methods that mutate the instance)'. Set(T) { void remove(T item) out () { if (old this.contains(item)) { assert(this.size + 1 == (old this.size())); } assert(!this.contains(item)); // so far so good. for (T each; old this) { if (each != item) { assert(this.contains(item)); } } /* ops, it won't work because the "old this" expression will yield a reference * to the this object, and here it's already mutated. The correct expression is * "(old this.clone())" ensuring that we get a snapshot of the this object from * before the method execution. */ }; }

Well, that's what you get if you really want to compare two sets, only one of which is available at a time. I'd really just leave it, settle with simpler preconditions and place some trust on the programmer... I wouldn't find very complicated examples in Eiffel's libraries, either; in particular, no clone()'s in old expressions. I looked at, for example, the equivalent BINARY_SEARCH_TREE_SET at http://docs.eiffel.com/libraries/base/reference/structures/set/binary_search _tree_set.html#f_prune which has the similar postcondition removed_count_change: old has (v) implies (count = old count - 1) but does not have the last check. -Antti
Aug 26 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 Back to the min() problem. Ideas only keep getting wilder... well, do
 you remember how we did it in C times: Macro! Of course!

 #define min(x, y) ((x) < (y) ? (x) : (y))

 This actually works better (except for the side-effects of call-by-name
 parameter passing) than any of its C++ equivalents, since you can do
 things like

 int x = 5;
 const float y = 1.0;

 float z = min(x, y);

 No need for different "const" methods, overloading or anything! Amazing!

Then what we would like is is template with automatic return type deduction (which will also require implicit instanciation). This would be a great plus for metaprogramming. We may be able to uses standard template syntax for the function definition: template (R, S, T) R min(S s, T t) { return s < t ? s : t; } or we might uses a syntax that compute the return type: template (S, T) min(S s, T t) returns typeof(expr(s, t)) { } where the returns type is obtained from an expression or from some other deduction like a typedef inside template class: instance MyClass(S, T).my_typedef If we have otherwise about the same power as in C++ for templates (i.e. have the power to implement code similar to boost, C++ Template (book) or Modern C++ Design (book) and Loki), those addition would make metaprogramming far more powerfull that what we have in C++... We would have some new keyword like typeof, constnessof, and a few boost style function and template that would allows us to manipulate that information...
 Compare this with what Andrei Alexandrescu did to get the (nearly)
 similar effect with templates:

 http://www.cuj.com/documents/s=7996/cujcexp1904alexandr/

 By the way, he has an interesting comment: "Minimum and maximum are two
 simple concepts present both in math and in the real life.  If a
 programming language is unable to express simple concepts of math and
 life, then there is something deeply wrong with that language."

 Anyway - macros seem to work. Why is this possible? Well, because min()
 is not an actual function call but merely a textual substitution. Well,
 what language feature was introduced in C++ (and later, in C) to get rid
 of a certain usage of macros?

 Taking Andrei's challenge, let's bring forth the final solution: inline
 functions.

 I wouldn't mean to use inline functions as a means to perform premature
 optimization, a purpose which programmers are often accused of misusing.
 But I simply would want to take advantage of the fact that inline
 functions can "see" the context where they are used, and therefore they
 would also be able to provide different kinds of code than usual
 functions. Actually, after an inline function were expanded several
 times, the compiler could gather them to a single (if possible) function
 and optimize the inlined code to a function call :)

 One thing that inline functions could provide would be determining the
 return type based on argument types. In fact, the inline function could
 work directly on the symbolic environment of the caller;
 assume

 inline Symbol min(Symbol x, Symbol y) {
     return x < y ? x : y;
 }

 This would expand similarly to the macro:
 void g(int x, float y) {
     float z = min(x, y); // expands into:
     // float z = x < y ? x : y;
 }

 It would have to have different specialisations; for non-symbol
 expressions, the following would be expanded:

 inline T min(T x, T y) {
     // as usual
 }

 Inline functions would of course have to have some kind of template-like
 implicit instantiation mechanism (which D templates is soon going to
 get, I hope) and ability to specialize on different types. And they
 could naturally be used to implement variable-sized argument lists
 type-safely...

 Hmm, I think I got sidetracked a bit. Could be time for sleep.

Aug 26 2003
prev sibling parent "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> escreveu na mensagem
news:slrnbkntuv.83p.jsykari pulu.hut.fi...
 Ok, let's drop immutable and just talk about const.

But I like immutable so much... ;) [snip]
 Okay, now I think I have an idea about the fundamental problem. The
 min() function can be used as an example of the general idea. The
 function must return one of its arguments, whether mutable or immutable.
 At the same time it must provide the guarantee that it won't modify its
 arguments -- we'd like the type system to ensure that the only thing
 that "min(T, T)" is allowed to do is to pass one of its arguments back
 to the caller.

That's it.
 One way to ensure this is to make its arguments const; but then you'd
 have to make its return type const, as well, or the following wouldn't
 compile: (Let's leave the bodies away -- everybody probably knows what
 "min" looks like if he or she has read this far :)

 I'll drop the template syntax because it has nothing to do with const
 really. Assume that T is an int or actually, reference type would be
 better to illustrate the const semantics.

[snip]
 Don't use "const" as a type modifier at all, but merely as a way of
 documenting the function's behavior (as in "I won't change this
 parameter"). Enter contracts. Like so:

 T min(const T x, const T y) {
     // implementation...
 }
 out() {
     // mathematical properties of min(x,y)
     assert(result <= x);
     assert(result <= y);
     // it's one of them
     assert(result === x || result === y);
     // I didn't change my parameters, I promise; these would be
     // generated by "const"
     assert(old x == x);
     assert(old y == y); // Here we would actually have to rely on
     // deep_clone or similar, as you mentioned below. Tricky notion,
     // comparing something that exists now to something that existed
     // earlier in time
 }

 Side note: Don't you just love when the function's postconditions
 actually describe perfectly what the function does! Reminds of me of the
 good old combinator function in purely functional languages. It takes a
 function of type ('a -> 'b) and a function of type ('b -> 'c) and
 returns a function of type ('a -> 'c). Now what could a function of this
 type do? The notation "'something" means generic type parameter, so it
 cannot assume anything about its types.  Well, what else can it do,
 then, than create a function that first calls the first function and
 then calls the second function on the result? So the function's type is
 a complete description of the function itself.

That would probably be a good compromise. But we still need a way to "attach constness" to a reference, so I can give to my caller a const reference. Otherwise we just solve one half of the problem. [snip interesting things about inline functions] Inline functions also solve just one part of the problem. Besides sometimes you can't inline the definitions (e.g. virtual functions).
      Some issues regarding mutability are discussed here

<http://lambda.weblogs.com/discuss/msgReader$8378?mode=topic&y=2003&m=8&d=2

 Tim Sweeney has some pretty good thoughts.


An interesting discussion. BTW, the guy who he was talking with, Vesa Karvonen, I used to work with some time ago. He's a smart guy; taught me a lot about programming. It's a small world, and particularly small in the area of functional languages and type theory :)

Yes, it's a very small world :)
 Uh, could you give an example of one hard case?

Sorry I meant: 'Also it's very hard to write "ensure" clauses on contracts of methods that have side-effects (i.e. methods that mutate


 instance)'.

 Set(T) {
     void remove(T item)
     out () {
         if (old this.contains(item)) {
             assert(this.size + 1 == (old this.size()));
         }
         assert(!this.contains(item));
 // so far so good.
        for (T each; old this) {
            if (each != item) {
                assert(this.contains(item));
            }
        }
 /* ops, it won't work because the "old this" expression will yield a
 reference
  * to the this object, and here it's already mutated. The correct


 is
  * "(old this.clone())" ensuring that we get a snapshot of the this


 from
  * before the method execution.
  */
     };
 }

Well, that's what you get if you really want to compare two sets, only one of which is available at a time. I'd really just leave it, settle with simpler preconditions and place some trust on the programmer... I wouldn't find very complicated examples in Eiffel's libraries, either; in particular, no clone()'s in old expressions. I looked at, for example, the equivalent BINARY_SEARCH_TREE_SET at

 _tree_set.html#f_prune

 which has the similar postcondition

 removed_count_change: old has (v) implies (count = old count - 1)

 but does not have the last check.

 -Antti

There are better contracts in the ELKS standards. They are pretty comprehensive (the String slicing includes more than 10 ensure clauses IIRC) and has to deal with some of these issues. Also there are papers only about this, specially one author talks about specifying mutability in contracts, to ensure that Set.put don't change the old contents of a Set, ditto for Stacks, Queues, etc., generalizing the notion to Observer design pattern. I don't seem to have the paper here, but if you're interested I can look around. It was about Eiffel, and using special deconstructors to decompose the object (in Stack he described an "item" operation returning the top of the stack and a "rest" operation giving everything except the top, in set he used a "choice" and "rest" pair of operations). --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.512 / Virus Database: 309 - Release Date: 19/8/2003
Aug 26 2003
prev sibling parent Farmer <itsFarmer. freenet.de> writes:
Antti Sykäri <jsykari gamma.hut.fi> wrote in 
news:slrnbk5c5l.4q6.jsykari pulu.hut.fi:

 Java, a blatant mockery of static typing, solves the "const" by
 providing a view to the container (via
 java.util.Collections.unmodifiableCollection or similar) which looks
 exactly like the original, but throws an UnsupportedOperationException
 when one tries to modify it.  No wonder there's a project trying to
 bring "const" to Java (http://pag.lcs.mit.edu/constjava/). [...]

ConstJava looks like a straight adaption of C++'s const notion. They just added the useful notion (for Strings etc.) of const classes. The paper (http://pag.lcs.mit.edu/constjava/ConstJava.pdf) talks about a runtime exception for const_casts, but I didn't find any details. Wonder how this works. Farmer.
Aug 26 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Fabian Giesen" <rygNO SPAMgmx.net> wrote in message
news:bhrn8p$251q$1 digitaldaemon.com...
 I agree that such limitations can always be worked around with inline

 or union hacks or stuff like that, but that's not of interest to me; if

 to go into the realm of undefined behavior in the first place to do

 it's perfectly okay if you get undefined behavior in return. :)

Yet you can break const using legal and defined Standard-conforming code, as I posted in this thread. The optimizer could make use of const if breaking it was only in the realm of undefined behavior. But it is not, and so const is useless. Not that I don't have a strong opinion about it <g>.
Sep 18 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 Yet you can break const using legal and defined Standard-conforming code,

 I posted in this thread. The optimizer could make use of const if breaking
 it was only in the realm of undefined behavior. But it is not, and so

 is useless.

It's only useless from the perspective of a compiler writer. For professional programmers (by which I mean those that observe the "contracts" of the libraries that they are using), it is anything but. I've found this whole debate quite perplexing. People are expending huge efforts to prove that const is useless from a strict point of view. I don't really think anyone would disagree with that proposition. (It'd be pretty hard to when we have "mutable" and "const_cast".) But no-one's argued successfully against the real value of const (which should have been named "readonly") which serves as Jiminy Cricket to the user. This is in just the same way that, say, speed limits on roads serve a useful function. They present an informed context within which you can exercise free will. You may choose to drive at 100mph on a winding mountain pass that has 50mph limit, but you bear the risk. I for one would not want to have engine-limiting mechanisms that prevent me from breaking the speed limit, even though most of the time I drive to it, in case I had some kind of emergency. In the same way, I'm quite happy as a coder (not a compiler writer) that const can be broken. Although such action is frowned upon, there are rare occasions where it is necessary. The majority of cases it is very good to have the (C++) compiler tell us that we cannot do something, albeit that we may recklessly choose to overwrite it. Yesterday you raised the issue of the deblank() function having the wrong semantics. If we had a readonly keyword in D, the issue would be moot. I want code to be self-documenting, and the compiler to help enforce that (to a reasonable degree). If we had "readonly", that could be achieved. I don't give a fig for optimisations based on putative vs actual read-only, and all that other guff, and will be thoroughly unperturbed if that is left out as it stands currently. But I remain strongly unconvinced that its absence from D is a +ve step. I'd be very interested to hear anyone to put forth an argument for such in response to what I (and others, who've commented similarly) want from a readonly/const keyword, rather than countering with the optimisation arguments.
Sep 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkdt7v$1vih$1 digitaldaemon.com...
 Yesterday you raised the issue of the deblank() function having the wrong
 semantics. If we had a readonly keyword in D, the issue would be moot.

Not exactly. Consider the case of passing a parameter that is int****p. If it is 'readonly', what part of it is readonly? p? *p? **p? ***p? ****p? all of them? To resolve the issue with deblank(), more than just the string reference (i.e. p) would have to be readonly.
 I want code to be self-documenting, and the compiler to help enforce that
 (to a reasonable degree). If we had "readonly", that could be achieved. I
 don't give a fig for optimisations based on putative vs actual read-only,
 and all that other guff, and will be thoroughly unperturbed if that is

 out as it stands currently. But I remain strongly unconvinced that its
 absence from D is a +ve step. I'd be very interested to hear anyone to put
 forth an argument for such in response to what I (and others, who've
 commented similarly) want from a readonly/const keyword, rather than
 countering with the optimisation arguments.

Fair enough, and I had given some earlier in this thread <g>. Let's discuss the one about self-documentation. I agree with you that code should be self-documenting, as I've argued that comments are invariably missing, out-of-date, incomplete, or wrong. The trouble with const being self-documenting is like checked exceptions in Java. Java issues a compile error if you call a function that throws something not listed in the exception specification. So, adding functionality to a function can entail going back through the entire static call chain editting all the exception specifications - so annoying that too many Java programmers, even good ones, tend to write try{f.foo();}catch{} just to shut up the compiler and get on with it. This, of course, completely subverts exception specifications and makes it far worse than not having exception specifications at all. (Even worse, despite being "exception specification correct", it is still possible to get exceptions not listed.) Const has similar problems. You can't just ignore const if it is in the language, as you'll need to inevitably interface with code that uses it. The shortest, easiest way to do it is to just throw in a few const_cast's and move on. Even worse, as I pointed out, there are legal, defined ways to pull the rug out from under const without using undefined behavior of unions, casts, inline assembler, etc. While the situation isn't near as bad as with exception specifications, the self-documenting nature of it isn't at all reliable. That said, there is a solution for const as a storage class. If it is put in read-only memory, it is const. No way around it, since the checking happens in hardware at runtime rather than compile time <g>.
Sep 19 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bkeah6$2k5u$1 digitaldaemon.com>, Walter wrote:
 The trouble with const being self-documenting is like checked exceptions in
 Java. Java issues a compile error if you call a function that throws
 something not listed in the exception specification. So, adding
 functionality to a function can entail going back through the entire static
 call chain editting all the exception specifications - so annoying that too
 many Java programmers, even good ones, tend to write try{f.foo();}catch{}
 just to shut up the compiler and get on with it. This, of course, completely
 subverts exception specifications and makes it far worse than not having
 exception specifications at all. (Even worse, despite being "exception
 specification correct", it is still possible to get exceptions not listed.)

 Const has similar problems. You can't just ignore const if it is in the
 language, as you'll need to inevitably interface with code that uses it. The
 shortest, easiest way to do it is to just throw in a few const_cast's and
 move on. Even worse, as I pointed out, there are legal, defined ways to pull
 the rug out from under const without using undefined behavior of unions,
 casts, inline assembler, etc. While the situation isn't near as bad as with
 exception specifications, the self-documenting nature of it isn't at all
 reliable.

This is a good summary of the similarities of const and exception specifications. But then we need to concentrate on the differences between them. - const is much more lightweight because it's just one bit of information in the interface. And you often get it right the first time. Even if you don't, you need to go through the call chain only once when you decide to add it. Exception specifications, on the other hand, can grow and grow, and (if you want to do it right) you have to traverse the call chain every time when you add an exception. - const affects the function's semantics directly. It tells what it can do with its arguments. This is unlike exception specifications, which might not even have anything to do with the function that they pass through. -Antti
Sep 19 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbmlrr3.hfa.jsykari pulu.hut.fi...
 This is a good summary of the similarities of const and exception
 specifications.

 But then we need to concentrate on the differences between them.

 - const is much more lightweight because it's just one bit of
   information in the interface. And you often get it right the first
   time. Even if you don't, you need to go through the call chain only
   once when you decide to add it.  Exception specifications, on the
   other hand, can grow and grow, and (if you want to do it right) you
   have to traverse the call chain every time when you add an exception.

If you add a const to a type, that can ripple downwards through the call chain, affecting a lot of functions that are quite irrelevant. Inevitably, one of those rippled functions will be modifying its argument. This has happened to me :-(. There's a powerful temptation to just put in a const_cast and forget about it rather than reengineer.
 - const affects the function's semantics directly. It tells what it can
   do with its arguments.  This is unlike exception specifications, which
   might not even have anything to do with the function that they pass
   through.

I agree that the const problem isn't nearly as bad as the exception specification one.
Sep 19 2003
parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 This is a good summary of the similarities of const and exception
 specifications.

 But then we need to concentrate on the differences between them.

 - const is much more lightweight because it's just one bit of
   information in the interface. And you often get it right the first
   time. Even if you don't, you need to go through the call chain only
   once when you decide to add it.  Exception specifications, on the
   other hand, can grow and grow, and (if you want to do it right) you
   have to traverse the call chain every time when you add an exception.

If you add a const to a type, that can ripple downwards through the call chain, affecting a lot of functions that are quite irrelevant. Inevitably, one of those rippled functions will be modifying its argument. This has happened to me :-(. There's a powerful temptation to just put in a const_cast and forget about it rather than reengineer.
 - const affects the function's semantics directly. It tells what it can
   do with its arguments.  This is unlike exception specifications, which
   might not even have anything to do with the function that they pass
   through.

I agree that the const problem isn't nearly as bad as the exception specification one.

IMO the problem in C++ is the fact that we have to explictly add const (for member functions) and not the other ways so it is easy to forgot it and (and this will happen in a third-party library you don't want to change)... so my opinion is that member function (and in parameter) should be const by default... That way most of the changes caused by an initial forgotten const would be avoided... const does have its used to validate code... and to ensure that an object would not be (reasonably) modified. In fact, if we knows an object should not be modified, we uses const and the compiler will issue an error if we accidently try to call a function that modify the object. Maybe, we should support constness only on predefined types, enumerations, pointers, struct and class that are final (no virtual members) and uses a constant interface for classes if we want to prevent modifications: interface Reader { } // Only read interface Writer : Reader { } // Modify object class MyClass : Reader, Writer { } // Actual class void f(Reader r) { } void g(Writer w) { } MyClass c; f(reader); Reader rc = c; g(rc); // Compile-time error So my opinion is that we should have const but modify it a bit to avoid the common pitfall of C++ (forgetting a const on a method). For parameter, D is already better that C++ since it has in, out and inout.... with the proper default (i.e. in --- assuming in means const).
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Philippe Mori" <philippe_mori hotmail.com> wrote in message
news:bkg1k3$q8b$1 digitaldaemon.com...
 This is a good summary of the similarities of const and exception
 specifications.

 But then we need to concentrate on the differences between them.

 - const is much more lightweight because it's just one bit of
   information in the interface. And you often get it right the first
   time. Even if you don't, you need to go through the call chain only
   once when you decide to add it.  Exception specifications, on the
   other hand, can grow and grow, and (if you want to do it right) you
   have to traverse the call chain every time when you add an



 If you add a const to a type, that can ripple downwards through the call
 chain, affecting a lot of functions that are quite irrelevant.


 one of those rippled functions will be modifying its argument. This has
 happened to me :-(. There's a powerful temptation to just put in a
 const_cast and forget about it rather than reengineer.

 - const affects the function's semantics directly. It tells what it



   do with its arguments.  This is unlike exception specifications,



   might not even have anything to do with the function that they pass
   through.

I agree that the const problem isn't nearly as bad as the exception specification one.

IMO the problem in C++ is the fact that we have to explictly add const (for member functions) and not the other ways so it is easy to forgot it and (and this will happen in a third-party library you don't want to change)... so my opinion is that member function (and in parameter) should be const by default... That way most of the changes caused by an initial forgotten const would be avoided... const does have its used to validate code... and to ensure that an object would not be (reasonably) modified. In fact, if we knows an object should not be modified, we uses const and the compiler will issue an error if we accidently try to call a function that modify the object. Maybe, we should support constness only on predefined types, enumerations, pointers, struct and class that are final (no virtual members) and uses a constant interface for classes if we want to prevent modifications: interface Reader { } // Only read interface Writer : Reader { } // Modify object class MyClass : Reader, Writer { } // Actual class void f(Reader r) { } void g(Writer w) { } MyClass c; f(reader); Reader rc = c; g(rc); // Compile-time error So my opinion is that we should have const but modify it a bit to avoid the common pitfall of C++ (forgetting a const on a method). For parameter, D is already better that C++ since it has in, out and inout.... with the proper default (i.e. in --- assuming in means const).

in does not mean const. The in/out/inout applies to the parameter (reference) whereas the readonly applies to the object. They're quite different. (I'm not calling it const, because "const" sucks as a term, and if D gets a "readonly" this will enable it to forgoe many of the problems with const without being accused of overlooking something)
Sep 19 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 So my opinion is that we should have const but modify
 it a bit to avoid the common pitfall of C++ (forgetting a
 const on a method). For parameter, D is already better
 that C++ since it has in, out and inout.... with the proper
 default (i.e. in --- assuming in means const).

in does not mean const. The in/out/inout applies to the parameter (reference) whereas the readonly applies to the object. They're quite different.

I should have said implies... An in parameter should not be modified inside a function (and if const support is eventually added to the language, it should be the default for in parameters... and otherwise it should be undefined what happen if we change a in parameter (the change may or may not be visible to the caller depending on werither a copy was made (a bit like in parameter in COM programming... If a proxy is used (remote call), then the change will not be visible and otherwise we should make changes...
 (I'm not calling it const, because "const" sucks as a term, and if D gets

 "readonly" this will enable it to forgoe many of the problems with const
 without being accused of overlooking something)

const and readonly are different concept... as generaly used. Typically by const, we want to talk about a C++ style constness (logical) while when readonly is used, we want to talk about hardware style readonly (physical). Ideally both concept should be exprimable with proper construct... I would like a language that would allows to express more such concepts than C++ but it seems that we make tradeoffs... we have added some new stuff (design by contract, static assertion, ...) but OTOH, we remove some usefull things, IMHO, that where present in C++... I would prefer to have more even if not everybody uses everything...
Sep 19 2003
prev sibling parent reply scott_mccaskill yahoo.com writes:
In article <bhmc8c$h12$1 digitaldaemon.com>, Fabian Giesen says...
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be
 immutable. Which is quite convenient: when you call a function with
 signature void f(const T*); you can be certain that it won't change
 your argument.

Unless someone casts your donstness away, which anyone can do without you ever knowing. Which means that const is really just a vague promise.

Remember that const is type information. The same could be argued of any ability of the programmer to overrule the static type system (non-dynamic downcasting, anyone?). Does the existence of such mechanisms negate the value of static type checking? Certainly not. As has been pointed out, C++ const is not an enabler for compiler optimizations, nor is it meant to be. What it does do is enable a programmer to say something about how an object should be used or how he uses an object and have the compiler enforce it. (Maybe I'm just lazy, but I like it when I'm able to get the computer to do grunt work so I don't have to. It's better at that sort of thing anyway.) And, just like with other forms of static type checking, there exist mechanisms (casts) to allow you to explicitly lie to the compiler, albeit at your own risk. Lastly, the idea that const should always imply bitwise immutability is a misconception IMO. The usual example is of an object that does some computationally expensive operation. If the externally visible state of the object cannot be changed by the operation, then the operation is logically const and should be labeled so even if the implementation does something mutable internally (say, caching the results). The operations on the cache may not be const, but if it's entirely an implementation detail then it makes no difference to the constness of the operation. Scott McCaskill
Aug 27 2003
parent "Philippe Mori" <philippe_mori hotmail.com> writes:
 Lastly, the idea that const should always imply bitwise immutability is a
 misconception IMO.  The usual example is of an object that does some
 computationally expensive operation.  If the externally visible state of

 object cannot be changed by the operation, then the operation is logically

 and should be labeled so even if the implementation does something mutable
 internally (say, caching the results).  The operations on the cache may

 const, but if it's entirely an implementation detail then it makes no

 to the constness of the operation.

Then your have mutable members for thinks that should not appears const (in worst case scenario) all members would end-up as being mutable... so your external state can be what you want it to be anyway. We might also need mutable function that would be allowed to be called from a const object but would be allowed to only changes mutable members and this should help remove the need to cast away constness in more situations that C++ does.... The real problem is when using code that cannot be modified and for which constness is not properly done.... but I think that if we uses mutable for those objects where some functions aren't const when they should, it would help... Also for parameters, since in is the default, we have implicit constness for those arguments... which should also help to get it right from the beginning and have properly written libraries... If more control is needed, then we might add immutable keyword in addition to const...
Aug 27 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Antti Sykäri" <jsykari gamma.hut.fi> wrote in message
news:slrnbjq9vr.mtu.jsykari pulu.hut.fi...
 So the standard says that if we've got pointer to a const object, we
 can't change it, but does not indeed say the object would be immutable.
 Which is quite convenient: when you call a function with signature void
 f(const T*); you can be certain that it won't change your argument.

The problem is that the standard doesn't preclude anyone *else* from changing the const data. For example: void f(int *p1, const int *p2) { int i = *p1; (*p2)++; int j = *p1; // oops! j != i } int *a; ... f(a, a); This is perfectly legal and defined behavior. This is one reason why const as a type modifier is useless for optimizers. And yes, this kind of code (in obfuscated ways) happens in real code. I know, because I found out about it the hard way :-(
Sep 18 2003
parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Walter wrote:

 The problem is that the standard doesn't preclude anyone *else* from
 changing the const data. For example:
 
 void f(int *p1, const int *p2)
 {
      int i = *p1;
     (*p2)++;

Er, what? The integer pointed to by p2 cannot be modified when accessed through p2. At least that's what the FAQ says. When looking at the ANSI C++ spec, i cannot figure anything out. It's apparently been written by people not at the peak of comprehesibility. The DMC agrees with me. Where is a step which assigns to *p2 without casting away const-ness one or another way? What is a standard compliant way which would not result in undefined behaviour? And in which cases does const_cast exactly have well-defined behaviour?
     int j = *p1;        // oops! j != i
 }
 
     int *a;
     ...
     f(a, a);
 
 This is perfectly legal and defined behavior. 

????????????????????????????????????????????????????? ?? Am i going nuts or is actually something wrong ??? ????????????????????????????????????????????????????? -eye
Nov 03 2003
parent "Walter" <walter digitalmars.com> writes:
"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:bo6k86$2dpj$1 digitaldaemon.com...
 Walter wrote:

 The problem is that the standard doesn't preclude anyone *else* from
 changing the const data. For example:

 void f(int *p1, const int *p2)
 {
      int i = *p1;
     (*p2)++;

Er, what?

Ah, I have it backwards. Put the const in front of p1.
Nov 03 2003
prev sibling next sibling parent "Peter Hercek" <vvp no.post.spam.sk> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:bhaupl$12t1$1 digitaldaemon.com...
 Matthew Wilson wrote:

Does anyone else think const in C++ is a poor attempt at letting the user
decorate info that a sophisticated enough compiler could be able to figure
out on its own?  Somewhat akin to the "register" keyword, which "aids" the
compiler by disallowing any possibility of aliasing the value stored?


Yes. Definately. Why not just have the compiler try to prove that constant data is never modified, rather than having me put 'const' keywords in all my parameter declarations? Is this what you're getting at? If so, I'm for it. It would eliminate all the cast nonsense 'const' creates when we use eachother's code.

From my point of view: 1) full const support is good 2) to write constst there is pain So I think the const should be in a language, it should be explicit and editor, should be able to add consts to my code when I write it and ask for the anotation. In the worst case compiler could do it. It is nice to see consts in souce code when you try to understand it, even when they can lie, it is an idicator what was intended. On the other side, they are not critical.
Aug 12 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Bill Cox" <bill viasic.com> wrote in message
news:bhaupl$12t1$1 digitaldaemon.com...
 Why not just have the compiler try to prove that constant data is never
 modified, rather than having me put 'const' keywords in all my parameter
 declarations?  Is this what you're getting at?  If so, I'm for it.  It
 would eliminate all the cast nonsense 'const' creates when we use
 eachother's code.

Frankly, I think the way to do this is to put const data into a 'read only' data segment. Then, the hardware does the checking for you. There would be no way to use clever casting, mutable, or other gymnastics to defeat it. And there'd be no need whatsoever to use const as a type modifier. Compilers for embedded systems tend to do this already, as the const data gets burned into a ROM. That's another big reason why I prefer const as a storage class.
Sep 18 2003
prev sibling parent reply "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bha4n0$8q2$1 digitaldaemon.com...
 Does anyone else think const in C++ is a poor attempt at letting the user
 decorate info that a sophisticated enough compiler could be able to figure
 out on its own?  Somewhat akin to the "register" keyword, which "aids" the
 compiler by disallowing any possibility of aliasing the value stored?

 also something the compiler can figure out for you, something that modern
 compilers do.  They even do a pretty good job at it, from what I

 though C++'s laxity with pointers allows hideous data flow spaghetti that
 even the best compilers cannot sort out.

that's only "register" in C (afaik) register in C++ just means do things as fast as pos, try this as hello.cpp and hello.c with gcc void loadup( int * fp, int iv ) { *fp = iv; } int main( int argc, char * argv[] ) { register int foo; loadup( &foo, argc ); return 0; } gcc hello.cpp (works no errors) gcc hello.c --- hello.c: In function `main': hello.c:7: warning: address of register variable `foo' requested I agree c++ const is very poor, and one of the biggest reasons ppl think gcc -03 is broken, if you use const slightly wrong it can optimise away code that should be run (and if you miss the odd volatile too). I was just about to write a page on the great uses of const or final as contracts between user and library writer when I realised ... its all pointless (Walter you've make a convert out of me, although volatile I think should still be possibly attached to an pointer (hw reg address)) initially I considered two things, one was having "signal in" which like the vhdl signal in means that the value is readable only by the function (unlike now where I can use params as locals {I think this is bad and evil, especially on risc arch's where is forces the compiler to flush the value from reg to stack}) and having a way to say "this 'ere item I've passed you by reference can will not get modified by the function I is calling" so as an example I chose strcpy if its extern then you have to say, this does not modify the src. extern (C) c_strcpy( char * dest, final char * src, int len ); if it where in D then the compiler would know `*src` is only read. void d_strcpy( char * dest, char * src, int len ) { while ( len--> 0 ) *dest++ = *src++; } either can be called with x_strcpy( foo, bar, 3 ); or x_strcpy( foo, final bar, 3 ); the latter would fail to compiler if for some reason x_strcpy was changed to write into the value referenced by src. of course this is all rather pointless as src and dest might overlap! I do belive that there is a real need to have an "assert if modified by function" or a way to pass by reference a value that "should" not change (assert if it does) as part of the lang rather than adding asserts and checks all throughout your code (same for closures and reference to stack items, these should not be storeable on the heap or in a stack frame behind them (where you came from stack dir) [so passable but not storeable outside the local scope and not returnable (aliases to them would be restricted to the same rules too)] you mention D as design by contract, will one of the contracts should be "I don't modify your values you've passed me by reference" this may seem like i'm saying give me const, but no, I would like a way a library writer can say I'll not change your stuff, and an application writer can say I only want to call this if it does no modify my values. they are not const they are immutable within the local scope.
Aug 12 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
So you're saying you want a version of 'in' that works by reference always?

Usually the compiler would be smart enough to do that when appropriate, but
one huge thing about pass by value vs. pass by reference is that either
you're going to change the source data and you don't want the function to be
affected (need pass by value) or you're going to change the source data (say
in another thread) and want the function to get the updates immediately.
'inout' does this, but it allows the function to write to the parameters.

I believe the default parameter passing convention should be pass by value.
I'll let you guys debate the usefulness of allowing the function to modify
its value parameters.

If you want pass by reference, use 'in' for readonly reference, 'inout' for
read/write reference, 'out' for writeonly reference.

Sean

"Mike Wynn" <mike.wynn l8night.co.uk> wrote in message
news:bhb8hd$1e0o$1 digitaldaemon.com...
 I do belive that there is a real need to have an "assert if modified by
 function" or a way to pass by reference a value that "should" not change
 (assert if it does) as part of the lang rather than adding asserts and
 checks all throughout your code (same for closures and reference to stack
 items, these should not be storeable on the heap or in a stack frame

 them (where you came from stack dir) [so passable but not storeable

 the local scope and not returnable (aliases to them would be restricted to
 the same rules too)]

 you mention D as design by contract, will one of the contracts should be

 don't modify your values you've passed me by reference"
 this may seem like i'm saying give me const, but no, I would like a way a
 library writer can say I'll not change your stuff, and an application

 can say I only want to call this if it does no modify my values.
 they are not const they are immutable within the local scope.

Aug 13 2003
parent "Mike Wynn" <mike.wynn l8night.co.uk> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bhdq4e$qj2$1 digitaldaemon.com...
 So you're saying you want a version of 'in' that works by reference

yes (basically) currently for example extern(Windows) BOOL ClipCursor( RECT * lpRect ); which in C is BOOL ClipCursor( CONST RECT * lpRect ); I guess is could be in D as extern(Windows) BOOL ClipCursor( inout RECT lpRect ); but its not either realy its extern(Windows) BOOL ClipCursor( in byref RECT lpRect ); as the API is defined to not to modify the RECT struct who's address you've passed.
 Usually the compiler would be smart enough to do that when appropriate,

 one huge thing about pass by value vs. pass by reference is that either
 you're going to change the source data and you don't want the function to

 affected (need pass by value) or you're going to change the source data

 in another thread) and want the function to get the updates immediately.
 'inout' does this, but it allows the function to write to the parameters.

the compiler (like most C++/C compilers [and Java] I believe) assume that any value not marked as volatile are not modified by any other thread during the function, so globals can be cached at any time, but not cached over function calls [they might modify globals anyway]
 I believe the default parameter passing convention should be pass by

 I'll let you guys debate the usefulness of allowing the function to modify
 its value parameters.

 If you want pass by reference, use 'in' for readonly reference, 'inout'

 read/write reference, 'out' for writeonly reference.

alas D does not have "reference" only pointer (personally I think D should ditch pointer (has to be array slice) and allow references `struct X * const foo` (auto derefed like java, which it already has for object rather than c++ & which can't be rereferenced) (obviously extern C need some rules about what to pass to remain compatible)
Aug 13 2003
prev sibling parent reply Ilya Minkov <midiclub 8ung.at> writes:
Bill Cox wrote:
 I would be very interested in hearing about the utility of const.  I'm 
 not disputing your assertion, but I haven't had the same experience.

It took me looooooong to remember... i was telling to myself all the time: there must be some use, there must be some use... and now i think i finally recall it! Temporaries, generated in C++ expressions, are const. This has to be to insure they can be cleaned up correctly. That is, making a function work with const, makes it more flexible in respect to temporaries. I can recall similar rules for some circumstances in (IIRC) Delphi and certainly Sather. I vaguely recall const solves thus memory leaks on temporaries. Maybe i've gotten something wrong. Just correct me. In D, this should be a non-issue because of GC -- except for performance. And i still don't think i understand, what's the sense of casting away const-ness - we have our mutable fields. Can anyone come up with a sane example? -eye
Aug 17 2003
parent reply "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 Temporaries, generated in C++ expressions, are const. This has to be
 to insure they can be cleaned up correctly. That is, making a
 function work with const, makes it more flexible in respect to
 temporaries. I can recall similar rules for some circumstances in
 (IIRC) Delphi and certainly Sather.

Nope, whether something's const or not doesn't change a bit about how it's cleaned up. There are two cases in which const makes a difference: 1. Temporaries are const so they cannot be passed by reference, but by const reference. This is mainly a convenience thing, while forbidding references to temporaries is a style issue - references to temporaries was considered to cause many problems when it was still allowed. Don't know whether it was a really big issue or not though, wasn't using C++ at the time :) 2. For some data structures, certain optimizations can be made when it's known that the data structure isn't changed during traversal; so for certain classes calling functions with const parameters or on const objects will cause completely different code to be executed than without. This can cause both notable performance advantages and notable headaches during debugging when you're not expecting it. :)
 And i still don't think i understand, what's the sense of casting away
 const-ness - we have our mutable fields. Can anyone come up with a
 sane example?

Casting away const-ness should be outright forbidden and done away with, because as I already argued it renders the whole const qualifier into just a vague promise. However mutable is relatively recent, so I guess const_cast is still in C++ for backwards-compatibility issues (like so many things). -fg
Aug 18 2003
parent reply Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
In article <bhqmei$l2q$1 digitaldaemon.com>, Fabian Giesen wrote:
 Casting away const-ness should be outright forbidden and done away with,
 because as I already argued it renders the whole const qualifier into just
 a vague promise. However mutable is relatively recent, so I guess const_cast
 is still in C++ for backwards-compatibility issues (like so many things).

"Dag Brück and others reviewed considerable amounts of real code to see which casts were casting away const and which of those could be eliminated using 'mutable'. This study confirmed the conclusion that "casting away 'const'" cannot be avoided in general and that 'mutable' appears to eliminate casting away 'const' in less than half of the cases where it is needed in the absence of 'mutable'." D&E, §13.3.3 -Antti
Aug 18 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Antti Syk=E4ri wrote:
 "Dag Br=FCck and others reviewed considerable amounts of real code to s=

 which casts were casting away const and which of those could be
 eliminated using 'mutable'. This study confirmed the conclusion that
 "casting away 'const'" cannot be avoided in general and that
 'mutable' appears to eliminate casting away 'const' in less than half o=

 the cases where it is needed in the absence of 'mutable'."

That's about changing existing code - which might be unreasonable... When designing new code, things are different. There is an opinion, that = when someone casts away const-ness, this means illogical design which=20 can be avoided from the beginning on. I don't have enough experience to=20 say whether it's true or not, but i would like to think that this=20 statement is true. I'm looking for counter-examples: maybe anyone can=20 give me a hint? -eye
Aug 18 2003
next sibling parent "Philippe Mori" <philippe_mori hotmail.com> writes:
IMO, if the default was const, the situation would be a bit better...
since forgetting the modifier would be catched as soon as someone
try to modify something instead of waiting till someone try to pass
a const something where a modifiable object is expected.

I think that const is clearly desirable for pointers to struct,
intergral type, other pointers (multi-level indirection) and
enumeration.

For class object, I think it is a bit less usefull and a bit more painfull
since for member functions we could need both cases particulary
if we want to returns a pointer (reference) to a sub-object
(or a container element).... but OTOH const in those case
in very usefull as we can provide different behavior (direct
access vs a copy) for optimisation purpose... and it allows
us tio ensure that at the same time we can prevent copy and
modification of a given object...

I also agree that in well designed code, const_cast should
not be necessary at all. The problem is often in libraries
where some const are missing and we try to uses them from
correct code where const is not missing...

I think that the best would be that we have a way to force
the compiler but by default the compiler could be smarter
(i.e. verify itself if something is modified) in m any cases.

I do think that in, inout and out will help solve most of the
problem related with constness as by default parameters
are in (which should imply either by value or const reference)

"Ilya Minkov" <midiclub 8ung.at> a écrit dans le message de
news:bhrhij$1suj$1 digitaldaemon.com...
Antti Sykäri wrote:
 "Dag Brück and others reviewed considerable amounts of real code to see
 which casts were casting away const and which of those could be
 eliminated using 'mutable'. This study confirmed the conclusion that
 "casting away 'const'" cannot be avoided in general and that
 'mutable' appears to eliminate casting away 'const' in less than half of
 the cases where it is needed in the absence of 'mutable'."

That's about changing existing code - which might be unreasonable... When designing new code, things are different. There is an opinion, that when someone casts away const-ness, this means illogical design which can be avoided from the beginning on. I don't have enough experience to say whether it's true or not, but i would like to think that this statement is true. I'm looking for counter-examples: maybe anyone can give me a hint? -eye
Aug 18 2003
prev sibling parent reply "Scott McCaskill" <scott mccaskill.org> writes:
The canonical example of a good/useful const_cast in C++ is to avoid
duplicate code when you have const and non-const methods that do the same
thing.  Say I have some kind of array-like class in C++:

class MyArray
{
public:
  T& operator[](unsigned i)
  {
    // (imagine non-trivial code here)
    return result;
  }

  const T& operator[](unsigned i) const
  {
    // Without const_cast, I'd be forced to copy & paste (and maintain!)
    // the non-trivial code from above.  However, as the implementor of
    // this class, I _know_ that this is a perfectly sensible cast,
therefore
    // the language should not get in my way by trying to save me from
    // myself.
    return const_cast<MyArray*>(this)->data()[i];
  }
};

I haven't used D enough to have a good feel for how much it might or might
not benefit from having something like C++ const, but I do know that I would
definitely miss it from C++ in spite of its shortcomings.  It's extra type
info, which is quite useful in a very static-type-oriented language such as
C++.  It is _immensely_ useful to be able to specify all the places that I,
the programmer, think that something shouldn't be changed and then enlist
the help of the compiler to check all of those places automatically at
compile time.

Yes it can be used inappropriately, but the fact that a language feature can
be abused does not mean it's not useful or does not have its place (witness
goto, pointers, unions, inline asm).  I find such arguments appealing from a
theoretical perspective but inadequate in practice.

You could rely on run time tests (DBC/unit tests/assert/whatever), but what
if the contract violation happens only under certain rare circumstances?  In
this case, the compiler has the advantage of seeing _all_ of the code,
regardless of how often (or if) it actually gets executed.  Even if the unit
tests do catch all such violations, I would think it would be preferable to
find out about them sooner if it's easy to do so.  DBC/unit tests and static
type checking are compliments, not substitutes.

-- 
Scott McCaskill


"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bhrhij$1suj$1 digitaldaemon.com...
Antti Sykäri wrote:
 "Dag Brück and others reviewed considerable amounts of real code to see
 which casts were casting away const and which of those could be
 eliminated using 'mutable'. This study confirmed the conclusion that
 "casting away 'const'" cannot be avoided in general and that
 'mutable' appears to eliminate casting away 'const' in less than half of
 the cases where it is needed in the absence of 'mutable'."

That's about changing existing code - which might be unreasonable... When designing new code, things are different. There is an opinion, that when someone casts away const-ness, this means illogical design which can be avoided from the beginning on. I don't have enough experience to say whether it's true or not, but i would like to think that this statement is true. I'm looking for counter-examples: maybe anyone can give me a hint? -eye
Aug 19 2003
parent reply Ilya Minkov <midiclub 8ung.at> writes:
Scott McCaskill wrote:
 The canonical example of a good/useful const_cast in C++ is to avoid
 duplicate code when you have const and non-const methods that do the same
 thing.  Say I have some kind of array-like class in C++:

Why do you need a non-const version at all? -eye
Aug 20 2003
next sibling parent "Fabian Giesen" <rygNO SPAMgmx.net> writes:
 Why do you need a non-const version at all?

Because the (class-)const version only returns a const reference. -fg
Aug 20 2003
prev sibling parent "Scott McCaskill" <scott mccaskill.org> writes:
"Ilya Minkov" <midiclub 8ung.at> wrote in message
news:bhvj1j$1o2o$1 digitaldaemon.com...
 Scott McCaskill wrote:
 The canonical example of a good/useful const_cast in C++ is to avoid
 duplicate code when you have const and non-const methods that do the


 thing.  Say I have some kind of array-like class in C++:

Why do you need a non-const version at all?

So I can write this: // given: MyArray& a a[0] = 5; -- Scott McCaskill
Aug 20 2003
prev sibling parent reply "Philippe Mori" <philippe_mori hotmail.com> writes:
 1) Too complicated (look at all the wierd rules and perterbations it

 with template specialization and overloading).

I think this is right that the interaction is too complicated and it often cause duplicate code... but IMO we should modify the ways it works to avoid the problems while keeping the benefits. Also one think that make it complicate in C++ is the way declaration works particulary when there are some indirection level (i.e. pointers). For example, in C++, we have const int a; int const a; That mean the same thing. Alone, it is not too complicated but with pointers this can causes some confusion...
 2) Too confusing.

I think we should modify the concept and have distinct keyword for each things... This is done at least in part by using in, inout and out parameter...
 3) Insufficient utility.

I don't agree on that. I think if the compiler would be validating it and it would be impossible to break it (i.e. no const_cast or a different keyword for immutable data), then it would much more usefull.
 4) Optimizers can't reliably use the info anyway.

It should be done in a way that the optimizer would be able to uses the information because the compiler should guaranties that constant data is not modified (by any means) and should not provide a way to break it. We should not allows removing const anywhere... and we should not allows aliasing to occurs globally...
 5) Ugly.

What it is ugly IMO with C++ solution is that it cause code duplication that should not occurs in some cases. I think this should be handled by having more keyword so that things can be expressed exactly... For example, we should have a modifier "variable" that would be the opposite of "const" and we should also have "immuable" which would be the opposite of mutable (or does inout and out parameters is sufficient ?). I don't think so at least when pointer are used. I think that ideally we should be able to express the concept that a function won't modify the data (in parameter) and the concept that some data could not be modified (immutable data). immutable data could be passed to const function without problem but it would be also be possible to define function that only accept immutable (or static) data so that the compiler could do some optimizations... I think it should also be possible to express the constness of something (for example the result of a function including members) from the constness of something else (this, result of another function call, parameters,...) including combinaisons... (i.e. any const implies result is const).
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bgvdh2$1t4n$1 digitaldaemon.com...
 What's the rationale again?

 "Walter" <walter digitalmars.com> wrote in message
 news:bgvd22$1sna$1 digitaldaemon.com...
 "Chris Sokol" <chris echosproject.org> wrote in message
 news:bgv1t6$1ijj$1 digitaldaemon.com...
 Does D support it at all?

D supports const as a storage class, but not as a type modifier.



Aug 12 2003
parent Ilya Minkov <midiclub 8ung.at> writes:
Philippe, you're speaking my mind!

-i.
Aug 12 2003