const promises (was New linked list)

[kris]

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?