New linked list

[Sean Kelly]

Walter Bright wrote:
> 
> If you don't mess with the iteration state, it will probably work. But 
> the spec won't guarantee it will work, as the intention of foreach is to 
> enable aggressive compiler optimizations. I want to leave the door as 
> wide open to that as possible.

Understood.

>> If ptr is ever passed by reference to an opaque function then there is 
>> no way to determine whether the data referenced by ref may change 
>> within the life of the program.  In fact, the same could be said if 
>> ref were ever passed by reference to an opaque function implemented in 
>> any language other than D, as one must assume that the const attribute 
>> could be ignored.  Frankly, this has me wondering whether it's 
>> possible to enforce any sort of const behavior without data movement 
>> in the face of aliasing.  For example, in instances where const data 
>> is being passed to an opaque code segment it should be possible to 
>> instead make a copy in a write-protected memory page and pass a 
>> reference to that instead, similar to how passing structs by value to 
>> functions works now.  This would result in a run-time error if a 
>> modification occurred to such data, similar to what happens for 
>> modifications to const data in D now.  But as far as I know it isn't 
>> possible to mark arbitrary memory ranges as read-only.
> 
> It isn't possible to prevent the programmer from subverting the rules 
> and modifying memory. The only thing that can be done is to label such 
> as "undefined behavior".

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.


Sean