digitalmars.D - secure const and
- Fawzi Mohamed (27/27) Apr 06 2008 I have tried to move part of this argument to the wiki.
- Jason House (8/43) Apr 06 2008 Any way to add a table of contents?
- Fawzi Mohamed (4/20) Apr 06 2008 Restructure it as you see fit to improve the ability to make the wiki ev...
I have tried to move part of this argument to the wiki. I have created a page at http://www.prowiki.org/wiki4d/wiki.cgi?TransitiveConst feel free to add to it. My main point is that I like Stevens proposal, but I think it should be seen as a hole to implement *secure* relaxations of the const concept, and so it should be clearly marked as a hole not to be used unless absolutely needed (and that will be in low level libraries). The secure abstractions are secure enough to be allowed also in pure functions and invariant data structures, without breaking anything (only extension 2 adds a constraint more to the optimizations allowed, namely that copied data should be synchronized, but as I describe it still a very well behaved extension). So I want that even pure functions have access to these mutable parts of the object, and if something bad happens the fault is obviously the fault of the programmer that used the hole in const in a bad way. This will make pure function more flexible, faster, and more likely to be written and used, something from which everybody should profit. I think that I identified all reasonable use of mutable state in a const object, if you think I missed something, please add it. As I say in the wiki also haskell (a language that considers provability quite important) has an uncontrolled hole (unsafePerformIO) that *is* used in special cases and it is the responsibility of the coder to make sure that it is used correctly. Also the monads laws are not verified by the compiler, it is just assumed that the implementor wrote them correctly. Fawzi
Apr 06 2008
Fawzi Mohamed wrote:I have tried to move part of this argument to the wiki. I have created a page at http://www.prowiki.org/wiki4d/wiki.cgi?TransitiveConst feel free to add to it. My main point is that I like Stevens proposal, but I think it should be seen as a hole to implement *secure* relaxations of the const concept, and so it should be clearly marked as a hole not to be used unless absolutely needed (and that will be in low level libraries). The secure abstractions are secure enough to be allowed also in pure functions and invariant data structures, without breaking anything (only extension 2 adds a constraint more to the optimizations allowed, namely that copied data should be synchronized, but as I describe it still a very well behaved extension). So I want that even pure functions have access to these mutable parts of the object, and if something bad happens the fault is obviously the fault of the programmer that used the hole in const in a bad way. This will make pure function more flexible, faster, and more likely to be written and used, something from which everybody should profit. I think that I identified all reasonable use of mutable state in a const object, if you think I missed something, please add it. As I say in the wiki also haskell (a language that considers provability quite important) has an uncontrolled hole (unsafePerformIO) that *is* used in special cases and it is the responsibility of the coder to make sure that it is used correctly. Also the monads laws are not verified by the compiler, it is just assumed that the implementor wrote them correctly. FawziAny way to add a table of contents? I'd also hope that the page would be restructured to give people the opportunity to talk about the pros of verious methods without arguing... Maybe something like a background section. Of course, then there can be a few proposal sections where arguing can be rampant :) There should probably be a separate section for bicycle shed discussions.
Apr 06 2008
On 2008-04-06 15:31:02 +0200, Jason House <jason.james.house gmail.com> said:Fawzi Mohamed wrote:doneI have tried to move part of this argument to the wiki. I have created a page at http://www.prowiki.org/wiki4d/wiki.cgi?TransitiveConst feel free to add to it. [....]Any way to add a table of contents?I'd also hope that the page would be restructured to give people the opportunity to talk about the pros of verious methods without arguing... Maybe something like a background section.Restructure it as you see fit to improve the ability to make the wiki evolve.Of course, then there can be a few proposal sections where arguing can be rampant :) There should probably be a separate section for bicycle shed discussions.Comments and Implementation Proposal sections should be more arguing free.
Apr 06 2008