www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - "constantness" in D

reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Constness is not only about possible bugs or ROM placement of variables as 
Kris rightly mentioned.
It is also about effectiveness and robustness of code and especially 
libraries - components.

Example:
I have a class:

class Url
{
    char[] _domain;
    char[] _filename;
    char[] _protocol;

    static Url parse( char[] url )
   {
       char[] buffer = unescape(url); // will always dup
       _domain = buffer[a..b];
       _filename = buffer[b..c];
       _protocol = buffer[c..d];
   }
   // current implementation
   char[] domain()        { return _domain.dup; }
   char[] filename()     { return _filename.dup; }
   char[] protocol()    { return _protocol.dup; }

   // this is extremely nice to have
   char[]:const  domain()      { return _domain; }
   char[]:const  filename()     { return _filename; }
   char[]:const  protocol()     { return _protocol; }
}

As you may see without const typical and robust library
implementation  approach follows to constant "joy of GC"
as  I ***must*** do 'dup' in
char[] domain()  { return _domain.dup; }
if I want my son to reuse my code.

If you think that this example is too abstract then
take a look into std/string.d  and comments in function:

char* toStrings(char[] s)
 /+ Unfortunately, this isn't reliable....

This is a typical example when "constness" will make


IMHO: without constness char[] cannot be considered
as a solutions for strings. I am pretty sure that without constness
it is just impossible to create reliable and consistent Phobos.

To D with love,

Andrew.
May 25 2005
next sibling parent reply "Kris" <fu bar.com> writes:
I'm a strong advocate for what you describe, but it may be better to talk
about this particular aspect in terms of "read only" rather than "const".
The latter has a somewhat sour flavour for many, and covers such a broad
gamut that its very name send shivers throughout the forum.

On the other hand, a "read only" modifer for types is just a sliver compared
to C++ const ~ its worth keeping that in mind. Such a modifier would allow
us to do all kinds of efficient and defensive programming, some of which you
have pointed out.

- Kris


BTW; it can be awkward to get the syntax right when deal with function
return values; how does one specify a read-only return?



"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d73kfp$f72$1 digitaldaemon.com...
 Constness is not only about possible bugs or ROM placement of variables as
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially
 libraries - components.

 Example:
 I have a class:

 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;

     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }

    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }

 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.

 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:

 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....

 This is a typical example when "constness" will make


 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.

 To D with love,

 Andrew.
May 25 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Kris, I agree with you that "read-only" is better.
Other useful metaphor for the same entity would be also
'ownership'.  Ownership implies run-time support.
With ownership mechanism it is possible to make
constantness and "read-only-ness" across library/component
boundaries.

Ownership (or owner) could be an attribute of chunk
of memory in the heap. Only owner - object or module allocated
the chunk can modify - write to it.
Presumably ownership does not require notation change.
Just new(owner) .... and someinstance.owner attribute.

I am skiping details of implementation intentionally as
this is just a wild idea tended to start sort of brain storming on the 
subject.

Any other ideas?

Andrew.





"Kris" <fu bar.com> wrote in message news:d73m38$omb$1 digitaldaemon.com...
 I'm a strong advocate for what you describe, but it may be better to talk
 about this particular aspect in terms of "read only" rather than "const".
 The latter has a somewhat sour flavour for many, and covers such a broad
 gamut that its very name send shivers throughout the forum.

 On the other hand, a "read only" modifer for types is just a sliver 
 compared
 to C++ const ~ its worth keeping that in mind. Such a modifier would allow
 us to do all kinds of efficient and defensive programming, some of which 
 you
 have pointed out.

 - Kris


 BTW; it can be awkward to get the syntax right when deal with function
 return values; how does one specify a read-only return?



 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d73kfp$f72$1 digitaldaemon.com...
 Constness is not only about possible bugs or ROM placement of variables 
 as
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially
 libraries - components.

 Example:
 I have a class:

 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;

     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }

    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }

 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.

 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:

 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....

 This is a typical example when "constness" will make


 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.

 To D with love,

 Andrew.
May 25 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"Andrew Fedoniouk" <news terrainformatica.com> wrote in message
news:d73o3h$14sr$1 digitaldaemon.com...
 Ownership (or owner) could be an attribute of chunk
 of memory in the heap. Only owner - object or module allocated
 the chunk can modify - write to it.
 Presumably ownership does not require notation change.
 Just new(owner) .... and someinstance.owner attribute.
The point of going to gc was to avoid having to keep track of ownership of memory. Down that lane leads to all the numbing complexity of C++ classes. Having to do an extra .dup now and then is a far lower cost than trying to keep track of ownership.
May 27 2005
next sibling parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"Walter" <newshound digitalmars.com> wrote in message
news:d78dsk$2h4e$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d73o3h$14sr$1 digitaldaemon.com...
 Ownership (or owner) could be an attribute of chunk
 of memory in the heap. Only owner - object or module allocated
 the chunk can modify - write to it.
 Presumably ownership does not require notation change.
 Just new(owner) .... and someinstance.owner attribute.
The point of going to gc was to avoid having to keep track of ownership of memory. Down that lane leads to all the numbing complexity of C++ classes. Having to do an extra .dup now and then is a far lower cost than trying to keep track of ownership.
Depends how you measure cost. If it's in efficiency, simplicity, then you're right. However, if it's in terms of robustness, confidence, then I think the case is anything but closed.
May 27 2005
parent reply John Reimer <brk_6502 yahoo.com> writes:
Matthew wrote:
 
 Depends how you measure cost. If it's in efficiency, simplicity, then you're
right.
 
 However, if it's in terms of robustness, confidence, then I think the case is
anything but closed.
 
Two lines? TWO lines? Wow! The new Matthew! ;-) -JJR
May 28 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
"John Reimer" <brk_6502 yahoo.com> wrote in message
news:d7a5g9$v8u$1 digitaldaemon.com...
 Matthew wrote:
 Depends how you measure cost. If it's in efficiency, simplicity, then you're
right.

 However, if it's in terms of robustness, confidence, then I think the case is
anything but closed.
Two lines? TWO lines? Wow! The new Matthew! ;-)
Sorry, mate. Just incredibly busy, all with C++-related things, atm. Am even not "lurking" on this ng. Just peeking in very infrequently. (I've now got 1892 unread messages on this ng. Probably be 4000 by the time I come back! <g>)
May 28 2005
parent John Reimer <brk_6502 yahoo.com> writes:
Matthew wrote:
 "John Reimer" <brk_6502 yahoo.com> wrote in message
news:d7a5g9$v8u$1 digitaldaemon.com...
 
Matthew wrote:

Depends how you measure cost. If it's in efficiency, simplicity, then you're
right.

However, if it's in terms of robustness, confidence, then I think the case is
anything but closed.
Two lines? TWO lines? Wow! The new Matthew! ;-)
Sorry, mate. Just incredibly busy, all with C++-related things, atm. Am even not "lurking" on this ng. Just peeking in very infrequently. (I've now got 1892 unread messages on this ng. Probably be 4000 by the time I come back! <g>)
No problem... I was just surprised that you showed such skill at brevity :-). I noticed you haven't been around for awhile (I dare say you've even been missed ;-) ). Life tends to get busy really fast, especially as things roll into summer. It's the same here; it feels like I have a hundred things on the go right now. Mixing work, family, and d is getting really challenging. :-( And where's Georg Wrede? That good chap has been silent for awhile too. I guess the sitution is the same for a lot of people. -JJR
May 28 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d78dsk$2h4e$1 digitaldaemon.com...
 "Andrew Fedoniouk" <news terrainformatica.com> wrote in message
 news:d73o3h$14sr$1 digitaldaemon.com...
 Ownership (or owner) could be an attribute of chunk
 of memory in the heap. Only owner - object or module allocated
 the chunk can modify - write to it.
 Presumably ownership does not require notation change.
 Just new(owner) .... and someinstance.owner attribute.
The point of going to gc was to avoid having to keep track of ownership of memory. Down that lane leads to all the numbing complexity of C++ classes. Having to do an extra .dup now and then is a far lower cost than trying to keep track of ownership.
I understand the problem. And agree with you. I am thinking about the 'owner' as sort of tag accessible through ptr.owner or ptr.tag. D runtime does not need to account it or interpret it in any way. ... some interesting idea is flying in the air, just need to catch it.... Andrew.
May 29 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 25 May 2005 21:48:41 -0700, Andrew Fedoniouk wrote:

 Constness is not only about possible bugs or ROM placement of variables as 
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially 
 libraries - components.
 
 Example:
 I have a class:
 
 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;
 
     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }
 
    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }
 
 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.
One could consider this as just a syntax or implementation issue. The addition of the ".dup" causes your object's data to be effectively const; that is 'not modifiable by the caller'. The mechanism to make it const is to provide a copy of the data that the caller can freely mess about with if they want to. If instead, you want the mechanism to be that the compiler detects these at compile time, then we have a problem. From memory, I think the argument against that mechanism is that because there are always some way to fool the compiler (eg. in line assembler code) so if it does not report an error, the coder has a false sense of security. The current, runtime mechanism, does not rely on a foolproof compiler, though at the cost of some performance, but it does guarantee const-ness. I suppose one could argue for a syntax addition to more clearly state the intention of the coder. The compiler would still implement const-ness as it does now, via data copy, but the coder's desire for const would be more visible to the reader. So maybe char[]:const funcA() { ... return a; } could be identical to char[] funcA() { ... return a.dup; } By the way, I notice that your class's member data is not marked private, thus anyone can modify it directly. Is that desired?
 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:
 
 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....
That isn't fair. The 'unreliable' code is commented out. You give the impression that the unreliable code is actually in the library.
 This is a typical example when "constness" will make

 
 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.
I've described that the .dup mechanism actually does implement the concept of read-only strings, in so far as the calling functions are prevented from modifying data you don't want them to. Given that, it is therefore possible to create a reliable Phobos (with regards to strings anyhow). -- Derek Melbourne, Australia 26/05/2005 2:57:52 PM
May 25 2005
next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
Hi, Derek, please see below,

 Constness is not only about possible bugs or ROM placement of variables 
 as
 Kris rightly mentioned.
 It is also about effectiveness and robustness of code and especially
 libraries - components.

 Example:
 I have a class:

 class Url
 {
     char[] _domain;
     char[] _filename;
     char[] _protocol;

     static Url parse( char[] url )
    {
        char[] buffer = unescape(url); // will always dup
        _domain = buffer[a..b];
        _filename = buffer[b..c];
        _protocol = buffer[c..d];
    }
    // current implementation
    char[] domain()        { return _domain.dup; }
    char[] filename()     { return _filename.dup; }
    char[] protocol()    { return _protocol.dup; }

    // this is extremely nice to have
    char[]:const  domain()      { return _domain; }
    char[]:const  filename()     { return _filename; }
    char[]:const  protocol()     { return _protocol; }
 }

 As you may see without const typical and robust library
 implementation  approach follows to constant "joy of GC"
 as  I ***must*** do 'dup' in
 char[] domain()  { return _domain.dup; }
 if I want my son to reuse my code.
One could consider this as just a syntax or implementation issue. The addition of the ".dup" causes your object's data to be effectively const; that is 'not modifiable by the caller'. The mechanism to make it const is to provide a copy of the data that the caller can freely mess about with if they want to. If instead, you want the mechanism to be that the compiler detects these at compile time, then we have a problem. From memory, I think the argument against that mechanism is that because there are always some way to fool the compiler (eg. in line assembler code) so if it does not report an error, the coder has a false sense of security. The current, runtime mechanism, does not rely on a foolproof compiler, though at the cost of some performance, but it does guarantee const-ness. I suppose one could argue for a syntax addition to more clearly state the intention of the coder. The compiler would still implement const-ness as it does now, via data copy, but the coder's desire for const would be more visible to the reader.
Constantness is not about can I or cannot fool the compiler (I can full this Turing machine in many ways) but rather about again efectiveness and robustness. Yes, I can spread copy-on-write across *my*code. But as a generic library designer I cannot force users to do this. It is just not fair. Having my example in mind imagine how much memory will take .dup approach for url "http://w3c.org".... For given Url class (this is just a model - not a real one) when use cases of modifications of its parts are rare, such memory allocation behavior is not something I am considering as a good design. And more - such Url is a short living class - parse-n-forget and highly desireable to do not left traces in the sky after. Yes, you can follow .NET way and say "memory is not a resource anymore" and allocate memory on each sneeze but I hope here is a community of realists.... Either const/read-only/ownership/whatever either .dup with copying GC and all consequences which .NET and Java are facing now.
 So maybe

   char[]:const funcA() { ... return a; }

 could be identical to

   char[] funcA() { ... return a.dup; }

 By the way, I notice that your class's member data is not marked private,
 thus anyone can modify it directly. Is that desired?
This just a mockup...
 If you think that this example is too abstract then
 take a look into std/string.d  and comments in function:

 char* toStrings(char[] s)
  /+ Unfortunately, this isn't reliable....
That isn't fair. The 'unreliable' code is commented out. You give the impression that the unreliable code is actually in the library.
Sorry, I did not have an intention to demonstrate unreliable code. My point is inside comment itself and the solution which might be implemented (code commented out). Consider I need to draw components of the URL on the screen. So on each WM_PAINT I need to allocate new strings... Or to store them in member variables thus effectively increase number of objects on GC controllable perimeter. In Java simple applet with let's say red background is 12 objects allocated on each paint. Doh! And they even asking why it is slow.... Application is just not working 20% of time, is it good design?
 This is a typical example when "constness" will make


 IMHO: without constness char[] cannot be considered
 as a solutions for strings. I am pretty sure that without constness
 it is just impossible to create reliable and consistent Phobos.
I've described that the .dup mechanism actually does implement the concept of read-only strings, in so far as the calling functions are prevented from modifying data you don't want them to. Given that, it is therefore possible to create a reliable Phobos (with regards to strings anyhow).
Sorry when I am speaking about reliable I am assuming that effectivness and robustness is a primordial requirements. Otherwise we will have a robust something which nobody will use. Again, I am not agianst D, I am just trying to think of how to make it even better. Andrew.
May 25 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 25 May 2005 23:31:49 -0700, Andrew Fedoniouk wrote:


[snip]

 Again, I am not agianst D, I am just trying to think of
 how to make it even better.
Yeah, I know that Andrew. So how could read-only data be implemented differently in D? Any ideas, given that a compiler can't catch all attempts to write to read-only data, and we can't really rely on the underlying hardware to help us? -- Derek Melbourne, Australia 26/05/2005 4:35:10 PM
May 25 2005
parent reply "Kris" <fu bar.com> writes:
"Derek Parnell" <derek psych.ward> wrote
 So how could read-only data be implemented differently in D? Any ideas,
 given that a compiler can't catch all attempts to write to read-only data,
 and we can't really rely on the underlying hardware to help us?
Au Contraire, sir; The compiler *can* catch all /accidental/ or /incidental/ attempts to write to data marked as read-only. If someone is hell-bent on circumventing that, then they can do so via assembly, or via pointer aliasing, if they really insist. What, I believe, Andrew is getting at is where the intent of the designer is clearly stated within the (enhanced) syntax ~ the compiler supports that by flagging every instance whereby that explicit contract is implicitly broken. One can write *cast(void *) 0 = 0; and the compiler does not stop you ~ yet the compiler goes out of its way to catch array indexing errors. Surely the same approach could be applied here; yes?
May 25 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Wed, 25 May 2005 23:56:29 -0700, Kris wrote:

 "Derek Parnell" <derek psych.ward> wrote
 So how could read-only data be implemented differently in D? Any ideas,
 given that a compiler can't catch all attempts to write to read-only data,
 and we can't really rely on the underlying hardware to help us?
Au Contraire, sir; The compiler *can* catch all /accidental/ or /incidental/ attempts to write to data marked as read-only. If someone is hell-bent on circumventing that, then they can do so via assembly, or via pointer aliasing, if they really insist.
I agree that a compiler can catch 'normal' references. It was the absurd, "hell-bent" methods that I was concerned with. If we can live with that, *and* make that clear in documentation, then fine.
 What, I believe, Andrew is getting at is where the intent of the designer is
 clearly stated within the (enhanced) syntax ~ the compiler supports that by
 flagging every instance whereby that explicit contract is implicitly broken.
Yep, that's a position I can support. If a coder explicitly marks something as read-only *and* the compiler detects an infringement of that then it should report an error.
 One can write *cast(void *) 0 = 0; and the compiler does not stop you ~ yet
 the compiler goes out of its way to catch array indexing errors. Surely the
 same approach could be applied here; yes?
Seems consistent to me. But it must be made clear to coders that if the compiler does not report a read-only access error, it does not absolutely guarantee that the application is free of such problems; it just means that the compiler didn't find any. -- Derek Melbourne, Australia 26/05/2005 4:59:36 PM
May 26 2005
parent reply "Kris" <fu bar.com> writes:
"Derek Parnell" <derek psych.ward>
 One can write *cast(void *) 0 = 0; and the compiler does not stop you ~
yet
 the compiler goes out of its way to catch array indexing errors. Surely
the
 same approach could be applied here; yes?
Seems consistent to me. But it must be made clear to coders that if the compiler does not report a read-only access error, it does not absolutely guarantee that the application is free of such problems; it just means
that
 the compiler didn't find any.
Aye, sir. Nor does it guarantee the algorithms are correct <g>
May 26 2005
parent reply "Matthew" <admin.hat stlsoft.dot.org> writes:
From C++ FAQs, 14.04:

"Does const allow the comiler to generate more efficient code?

Occasionally, but that's not the purpose of const. The purpose of const is
correctness not optimization. That is, const 
helps the compiler find bugs, but it does not (normally) help the compiler
generate more efficient code."


That pretty much tallies with my opinion. const is _entirely_ about expressing
design, and obliging the compiler to 
enforce some of that design. It's attractions have _absolutely nothing_ to do
with code optimisation. All that is just 
Walterganda, which, even though we understand his perspective/bias as a
compiler writer, is flat out wrong, and misleads 
the design of D, for the worse.

FTR: Walter's the only C++ guru that I've ever heard talk in this way, and the
only one who thinks it's a bad concept 
(some would accept it's not the best expressed in C++). Although I don't
necessarily equate unanimity with rightness, I 
think it holds in this case. (All of which I've been saying to him in various
forums for the last few years, so hold not 
thine breath for change.)


"Kris" <fu bar.com> wrote in message news:d73t78$1ton$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward>
 One can write *cast(void *) 0 = 0; and the compiler does not stop you ~
yet
 the compiler goes out of its way to catch array indexing errors. Surely
the
 same approach could be applied here; yes?
Seems consistent to me. But it must be made clear to coders that if the compiler does not report a read-only access error, it does not absolutely guarantee that the application is free of such problems; it just means
that
 the compiler didn't find any.
Aye, sir. Nor does it guarantee the algorithms are correct <g>
May 30 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Matthew" <admin.hat stlsoft.dot.org> wrote in message 
news:d7eepv$1bu1$1 digitaldaemon.com...
 From C++ FAQs, 14.04:

 "Does const allow the comiler to generate more efficient code?

 Occasionally, but that's not the purpose of const. The purpose of const is 
 correctness not optimization. That is, const helps the compiler find bugs, 
 but it does not (normally) help the compiler generate more efficient 
 code."


 That pretty much tallies with my opinion. const is _entirely_ about 
 expressing design, and obliging the compiler to enforce some of that 
 design. It's attractions have _absolutely nothing_ to do with code 
 optimisation. All that is just Walterganda, which, even though we 
 understand his perspective/bias as a compiler writer, is flat out wrong, 
 and misleads the design of D, for the worse.

 FTR: Walter's the only C++ guru that I've ever heard talk in this way, and 
 the only one who thinks it's a bad concept (some would accept it's not the 
 best expressed in C++). Although I don't necessarily equate unanimity with 
 rightness, I think it holds in this case. (All of which I've been saying 
 to him in various forums for the last few years, so hold not thine breath 
 for change.)
Walter is demonstrating const-no-const position. I've got a proposal from him to use .dup as an ultimate solution ... I am still trying to get his joke right :)
 "Kris" <fu bar.com> wrote in message 
 news:d73t78$1ton$1 digitaldaemon.com...
 "Derek Parnell" <derek psych.ward>
 One can write *cast(void *) 0 = 0; and the compiler does not stop you 
 ~
yet
 the compiler goes out of its way to catch array indexing errors. 
 Surely
the
 same approach could be applied here; yes?
Seems consistent to me. But it must be made clear to coders that if the compiler does not report a read-only access error, it does not absolutely guarantee that the application is free of such problems; it just means
that
 the compiler didn't find any.
Aye, sir. Nor does it guarantee the algorithms are correct <g>
May 30 2005
parent reply Brad Beveridge <brad somewhere.net> writes:
Firstly, I must admit that I haven't read this whole thread - so if this 
is OT for the thread, please let me know.  At least the subject is on topic.

As I understand it, one of the primary reasons that D doesn't support 
constness is because it is hard (impossible) for the compiler to 
actually enforce constness.

Reading the "final vs const" post I had a flash of something (perhaps 
insipration, perhaps I was just hungry); D supports DBC very well.  DBC 
is far more flexible than mere constness, so one of the things that 
could be enforced by DBC _is_ constness - at least at function entry/exit.
So since true constness is hard/impossible to implement, should D 
programmers perhaps adopt the idea that any place you really want 
constness, enforce it with DBC?

Am I making any sense at all?  Perhaps not, but oh well :)

Thanks
Brad
May 31 2005
next sibling parent reply Sean Kelly <sean f4.ca> writes:
In article <d7i8pv$2a4k$1 digitaldaemon.com>, Brad Beveridge says...
Firstly, I must admit that I haven't read this whole thread - so if this 
is OT for the thread, please let me know.  At least the subject is on topic.

As I understand it, one of the primary reasons that D doesn't support 
constness is because it is hard (impossible) for the compiler to 
actually enforce constness.

Reading the "final vs const" post I had a flash of something (perhaps 
insipration, perhaps I was just hungry); D supports DBC very well.  DBC 
is far more flexible than mere constness, so one of the things that 
could be enforced by DBC _is_ constness - at least at function entry/exit.
So since true constness is hard/impossible to implement, should D 
programmers perhaps adopt the idea that any place you really want 
constness, enforce it with DBC?
See my reply to the "Java String vs wchar[]" thread :) Seab
May 31 2005
parent Brad Beveridge <brad somewhere.net> writes:
Sean Kelly wrote:
 In article <d7i8pv$2a4k$1 digitaldaemon.com>, Brad Beveridge says...
 
Firstly, I must admit that I haven't read this whole thread - so if this 
is OT for the thread, please let me know.  At least the subject is on topic.

As I understand it, one of the primary reasons that D doesn't support 
constness is because it is hard (impossible) for the compiler to 
actually enforce constness.

Reading the "final vs const" post I had a flash of something (perhaps 
insipration, perhaps I was just hungry); D supports DBC very well.  DBC 
is far more flexible than mere constness, so one of the things that 
could be enforced by DBC _is_ constness - at least at function entry/exit.
So since true constness is hard/impossible to implement, should D 
programmers perhaps adopt the idea that any place you really want 
constness, enforce it with DBC?
See my reply to the "Java String vs wchar[]" thread :) Seab
Your reply is much more concrete than mine. If I were smart enough I would have provided code too :) Brad
May 31 2005
prev sibling parent reply "Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:
Unfortunately, one of the tenets of Contract Programming (formerly 
known as DbC) is the principle of removability: code that is correct 
should not be affected by removal / insertion of contract 
enforcements.

Furthermore, Contract Programming enforcement is at runtime. While 
we can postulate that a compiler might be obliged to infer 
compile-time relationships from runtime contracts, this seems, at 
least at first thinking, to be a dubious notion, and likely to have 
only partial applicability.

"Brad Beveridge" <brad somewhere.net> wrote in message 
news:d7i8pv$2a4k$1 digitaldaemon.com...
 Firstly, I must admit that I haven't read this whole thread - so 
 if this is OT for the thread, please let me know.  At least the 
 subject is on topic.

 As I understand it, one of the primary reasons that D doesn't 
 support constness is because it is hard (impossible) for the 
 compiler to actually enforce constness.

 Reading the "final vs const" post I had a flash of something 
 (perhaps insipration, perhaps I was just hungry); D supports DBC 
 very well.  DBC is far more flexible than mere constness, so one 
 of the things that could be enforced by DBC _is_ constness - at 
 least at function entry/exit.
 So since true constness is hard/impossible to implement, should D 
 programmers perhaps adopt the idea that any place you really want 
 constness, enforce it with DBC?

 Am I making any sense at all?  Perhaps not, but oh well :)

 Thanks
 Brad 
May 31 2005
parent Sean Kelly <sean f4.ca> writes:
In article <d7iup8$5j2$1 digitaldaemon.com>, Matthew says...
Unfortunately, one of the tenets of Contract Programming (formerly 
known as DbC) is the principle of removability: code that is correct 
should not be affected by removal / insertion of contract 
enforcements.

Furthermore, Contract Programming enforcement is at runtime. While 
we can postulate that a compiler might be obliged to infer 
compile-time relationships from runtime contracts, this seems, at 
least at first thinking, to be a dubious notion, and likely to have 
only partial applicability.
But const correctness can be verified, somewhat, using DbC and a lot of cooperation. And since D currently offers us nothing in this regard, perhaps it's an approach worth mentioning. Sean
Jun 01 2005
prev sibling parent Sam <Sam_member pathlink.com> writes:
Come to think of it, 'const's were never always guaranteed in C++ because one
could do a 'const_cast<typename>(variable)' to remove the const-ness.

So

I guess....

Nothing is ever 'const' in this world.....
Everything changes........
'const' isn't what it used to be, or ever was????

Sam-
sam987883 yahoo.com
May 26 2005