const promises (was New linked list)

[Dave]

kris wrote:
> Walter Bright wrote:
>> Sean Kelly wrote:
>>
>>> Exactly.  And this was the motivation for my suggestion above.  If 
>>> there is no way to prevent the user from subverting a system built 
>>> upon reference attributes, then the only alternative I can think of 
>>> would be to build it upon the data itself.  D already has the const 
>>> storage type which does much the same thing: if the user manages to 
>>> outfox the compiler and modify data in ROM an error will occur.  A 
>>> similar measure of protection could be extended to dynamic data using 
>>> the page protection features supplied by the memory manager, but 
>>> there are some obvious problems:
>>>
>>> - To add data to a protected page the page must either be temporarily 
>>> unprotected, making it vulnerable to modification by another thread, 
>>> or it must be modified and the resulting error ignored (which is 
>>> quite slow).
>>>
>>> - Such protection is far from granular, as it requires copying data 
>>> the compiler cannot guarantee will not be modified by user code into 
>>> a protected memory page.  But as far as I'm aware, there is no other 
>>> way to obtain low-level support for read-only data.
>>>
>>> I can think of a few possible workarounds to the above problems, but 
>>> all of them would require special handing of references to const 
>>> data, and this seems unacceptable for a language like D.  But a 
>>> data-oriented const system seems the only option for something that 
>>> could actually be exploited by an optimizer.  It's just too easy to 
>>> work around any such attempt built into the language syntax itself.  
>>> Heck, inline assembler is an obvious and huge back-door to any 
>>> syntax-oriented protection mechanism.  There's simply no point in 
>>> even considering that route.
>>
>>
>> I have been thinking along the lines of making 'const' a promise *by 
>> the programmer* not to modify the data, and then the compiler will 
>> *assume* the promise is kept. 
> 
> 
> Is there a way you can do this whereby the source-level "tagging" of 
> these promises is explicit enough for a lint-like tool to operate upon 
> in a (fully) deterministic manner?
> 
> I ask because there seems to be two opposing needs involved to support 
> the notion of 'const': the complexity and performance of the compiler, 
> and the facility for a programmer to be informed when they invariably 
> make a mistake. As language users, we tend to rely upon the latter?

What I think most programmers would settle for is that const would be 
enforced in the 'easy' cases like:

int foo(const SomeObject o, const int[] arr)
{
     o.i = 20;     // error, is not an lvalue
     arr[10] = 30; // error, is not an lvalue
     o.bar();      // Ok
     o.baz();      // error, discards qualifiers
     o = new SomeObject; // Ok
//  ...
}

class SomeObject
{
     int i;
     int bar() const // a promise object isn't modified (like C++)
     {
         //i = 30; error, i is not an lvalue
         return i; // Ok
     }
     void baz()
     {
         i = 40;
     }
}

The compiler would just check that a member of any type of 
aggregate/object cannot be on the LHS of any assignment operator, or 
that a call to an object method is const, that's it.

If they modify a const param. through the reference, then all bets are off.

To reinforce the idea of const only for aggregates/objects, and to make 
the implementation as simple as possible, don't allow naked pointer 
variables to be const if that avoids a significant amount of complexity.

Then write the doc. (and spec.) to reflect this, so what const is 
expected to do is not ambiguous for either programmers or compiler 
developers.

Just a thought...

- Dave