On 26.09.2011 16:14, Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 04:46:07 -0400, Rainer Schuetze <r.sagita...@gmx.de>
wrote:
On 9/24/2011 9:30 AM, Andrei Alexandrescu wrote:
On 9/24/11 1:12 CDT, Rainer Schuetze wrote:
On 9/22/2011 4:10 PM, Andrei Alexandrescu wrote:
On 9/22/11 3:02 AM, Peter Alexander wrote:
On 22/09/11 7:04 AM, Andrei Alexandrescu wrote:
The initial submission got junked so I resubmitted:
http://www.reddit.com/r/programming/comments/knn5p/thoughts_on_immutability_in_d/
Andrei
Thanks for the reddit'ing. I launched up google analytics this
morning
and noticed a sudden spike. That could only mean one thing :-)
Out of interest, does anyone have any criticism of my post, esp. if
there's any technical inaccuracies (or just disagreement?)
You could have specified that e.g. mutable state can be implemented
safely with the help of a global hash table.
Andrei
If this is allowed by the compiler, doesn't that break all the
guarantees transitive immutability tries to make? Aren't we back to
"faith based programming" this way?
Not at all. Global mutable memory is what it is to everyone.
Andrei
I'm probably missing something, but what are the guarantees given by
the type system, if a property is implemented by a getter function:
int globId;
class C
{
@property id() const { return ++globId; }
}
int main()
{
immutable(C) c = new immutable(C);
return c.id;
}
Is c.id thread-safe? no! Is it constant? no! How does this help in
multi-threaded applications that access c?
I have argued about this in the very distant past.
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=68879
We already have a logical-const system, but implementing it is simply
low-performing and difficult to get right.
-Steve
Thanks for the link, I didn't know it was already discussed to deeath.
Good to know I'm not alone ;-)
OT: It's really hard to follow long threads in the web archives, the
overview of replies often gets completely out of sync. Is there a good
way/place to read them?
