Changeset 1386

Timestamp:

12/15/09 21:23:11 (15 years ago)

Author:

walter

Message:

bugzilla 3580 Update docs s/invariant/immutable/

Files:

• trunk/docsrc/const-faq.dd (modified) (3 diffs)

trunk/docsrc/const-faq.dd

@@ -10 +10 @@
-
-    $(ITEMR const, Why does D have const?)
-    $(ITEMR principles, What principles drove the D const design?)
-    $(ITEMR transitive-const, What is $(I transitive const)?)
-    $(ITEMR head-const, What is $(I head const)?)
-    $(ITEMR tail-const, What is $(I tail const)?)
-    $(ITEMR logical-const, What is $(I logical const)?)
-    $(ITEMR readonly, Why not use $(I readonly) to mean read only view?)
-    $(ITEMR java-const, Why did Java reject const?)
-    $(ITEMR cpp-const, How does const differ in C++?)
-nvariant
+mmutable
-    $(ITEMR const-parameters, Why aren't function parameters const by default?)
-    $(ITEMR static-members, Are static class members covered by transitive const?)
-nvariant
+mmutable
-    )
-
-$(ITEM const, Why does D have const?)
-
-nvariant
+mmutable
-    in D 2.0 and wonder if it is worth it.
-    )
-
-    $(OL
-
-    $(LI It makes function interfaces more self-documenting. Without
-    transitive const, for all pointer/reference parameters one must rely on
-    the documentation (which is always missing, out of date, or wrong). Note
-    that without transitivity, C++ const is nearly useless for such
-    self-documentation, which is why C++ programmers tend to rely on
@@ -194 +194 @@
-    $(P $(LINK http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4211070)
-    )
-
-$(ITEM cpp-const, How does const differ in C++?)
-
-    $(P C++ has a const system that is closer to D's than any other
-    language, but it still has huge differences:)
-
-    $(OL
-    $(LI const is not transitive)
-nvariant
+mmutable
-    $(LI const objects can have mutable members)
-    $(LI const can be legally cast away and the data modified)
-    $(LI $(CODE const T) and $(CODE T) are not always distinct types)
-    )
-
-nvariant
-
-nvariant
+mmutable
+
+mmutable
-    )
-
-$(ITEM const-parameters, Why aren't function parameters const by default?)
-
-    $(P Since most (nearly all?) function parameters will not be modified,
-    it would seem to make sense to make them all const by default,
-    and one would have to specifically mark as mutable those that would
-    be changed. The problems with this are:
-    )
-
@@ -246 +246 @@
----
-
-$(ITEM static-members, Are static class members covered by transitive const?)
-
-    $(P A static class member is part of the global state of a program,
-    not part of the state of an object. Thus, a class having a mutable
-    static member does not violate the transitive constness of an object
-    of that class.
-    )
-
-nvariant
-
-nvariant
+mmutable
+
+mmutable
-    This has many uses:
-    )
-
-    $(UL
-nvariant
+mmutable
-    when multiple threads read it.)
-    $(LI Data races, tearing, sequential consistency, and
-    cache consistency are all non-issues when working with
-nvariant
-nvariant
+mmutable
+mmutable
-    $(LI When doing a $(I deep copy) of a data structure,
-nvariant
+mmutable
-    $(LI Invariance allows a large chunk of data to be treated
-    as a value type even if it is passed around by reference
-    (strings are the most common case of this).)
-nvariant
+mmutable
-    to the programmer.)
-nvariant
+mmutable
-    memory, or even in ROMs.)
-nvariant
+mmutable
-    corruption bug, and it is possible to automatically check for
-    such data integrity.)
-nvariant
+mmutable
-    opportunities.)
-    )
-
-nvariant
+mmutable
-    worlds, so a single function can be used to accept both types
-    of arguments.)
-)
-
-Macros:
-    TITLE=const(FAQ)
-    WIKI=constFAQ
-    ITEMR=$(LI $(LINK2 #$1, $+))
-    ITEM=<hr><h3><a name="$1">$+</a></h3>