- book-keeping in the TODO section:

- removed closed, resolved, or off-the-table items
  - consolidated remaining items
- no changes to the spec

R=r
DELTA=116  (1 added, 102 deleted, 13 changed)
OCL=27596
CL=27640

doc/go_spec.html

@@ -1,134 +1,33 @@
 
 
 <!--
-Biggest open issues:
-[ ] General iterators
+Open issues:
 [ ] Semantics of type declaration:
 	- creating a new type (status quo), or only a new type name?
-	- also: declaration type T S; strips methods of S. why/why not?
-
-
-Decisions in need of integration into the doc:
-[ ] pair assignment is required to get map, and receive ok.
-[ ] len() returns an int, new(array_type, n) n must be an int
+	- declaration "type T S" strips methods of S. why/why not?
+	- no mechanism to declare a local type name: type T P.T
 
 
 Todo's:
 [ ] document illegality of package-external tuple assignments to structs
 	w/ private fields: P.T(1, 2) illegal since same as P.T(a: 1, b: 2) for
 	a T struct { a b int }.
-[ ] clarification on interface types, rules
-[ ] clarify tuples
-[ ] need to talk about precise int/floats clearly
-[ ] iant suggests to use abstract/precise int for len(), cap() - good idea
-    (issue: what happens in len() + const - what is the type?)
-[ ] fix "else" part of if statement
-[ ] cleanup: 6g allows: interface { f F } where F is a function type.
-	fine, but then we should also allow: func f F {}, where F is a function type.
-[ ] decide if and what to write about evaluation order of tuple assignments
+[ ] should probably write something about evaluation order of statements even
+	though obvious
+[ ] string conversion: string([]int{}) vs string(int) conversion. Former is
+	"inverse" of string range iteration.
+[ ] do we need explicit channel conversion (to change channel direction)?
+
 
 Wish list:
-[ ] enum facility (enum symbols that are not mixable with ints) or some other
-	mechanism to obtain type-safety which we don't have with int-only tags
-[ ] Gri: built-in assert() - alternatively: allow entire expressions
-	as statements so we can write: some_condition || panic(); (along these lines)
+[ ] enum symbols that are not mixable with ints or some other mechanism
+	(requirement that basic type aliases need conversion for compatibility)
 [ ] Helper syntax for composite types: allow names/keys/indices for
-	structs/maps/arrays, remove need for type in elements of composites
-
-
-Smaller issues:
-[ ] do we need channel conversion (channel direction)
-
-
-Closed:
-[x] Russ: If we use x.(T) for all conversions, we could use T() for "construction"
-    and type literals - would resolve the parsing ambiguity of T{} in if's -
-	switching to () for literals, conversion discussion still open
-[x] Russ: consider re-introducing "func" for function type. Make function literals
-	behave like slices, etc. Require no &'s to get a function value (solves issue
-	of func{} vs &func{} vs &func_name).
-[x] onreturn/undo statement - now: defer statement
-[x] comparison of non-basic types: what do we allow? what do we allow in interfaces
-	what about maps (require ==, copy and hash)
-	maybe: no maps with non-basic type keys, and no interface comparison unless
-	with nil[x]
-[x] clarify slice rules
-[x] what are the permissible ranges for the indices in slices? The spec
-	doesn't correspond to the implementation. The spec is wrong when it
-	comes to the first index i: it should allow (at least) the range 0 <= i <= len(a).
-	also: document different semantics for strings and arrays (strings cannot be grown).
-[x] reopening & and func issue: Seems inconsistent as both &func(){} and func(){} are
-    permitted. Suggestion: func literals are pointers. We need to use & for all other
-	functions. This would be in consistency with the declaration of function pointer
-	variables and the use of '&' to convert methods into function pointers.
-	- covered by other entry
-[x] composite types should uniformly create an instance instead of a pointer - fixed
-[x] like to have assert() in the language, w/ option to disable code gen for it
-	- added to wish list
-[x] convert should not be used for composite literals anymore,
-	in fact, convert() should go away - made a todo
-[x] provide composite literal notation to address array indices: []int{ 0: x1, 1: x2, ... }
-    and struct field names (both seem easy to do). - under "Missing" list
-[x] passing a "..." arg to another "..." parameter doesn't wrap the argument again
-	(so "..." args can be passed down easily) - this is documented
-[x] consider syntactic notation for composite literals to make them parsable w/o type information
-	(require ()'s in control clauses) - use heuristics for now
-[x] do we need anything on package vs file names? - current package scheme workable for now
-[x] what is the meaning of typeof() - we don't have it
-[x] old-style export decls (still needed, but ideally should go away)
-[x] packages of multiple files - we have a working approach
-[x] partial export of structs, methods
-[x] new as it is now is weird - need to go back to previous semantics and introduce
-    literals for slices, maps, channels - done
-[x] determine if really necessary to disallow array assignment - allow array assignment
-[x] semantics of statements - we just need to fill in the language, the semantics is mostly clear
-[x] range statement: to be defined more reasonably
-[x] need to be specific on (unsigned) integer operations: one must be able
-	to rely on wrap-around on overflow
-[x] global var decls: "var a, b, c int = 0, 0, 0" is ok, but "var a, b, c = 0, 0, 0" is not
-	(seems inconsistent with "var a = 0", and ":=" notation)
-[x] const decls: "const a, b = 1, 2" is not allowed - why not? Should be symmetric to vars.
-[x] new(arraytype, n1, n2): spec only talks about length, not capacity
-    (should only use new(arraytype, n) - this will allow later
-	 extension to multi-dim arrays w/o breaking the language) - documented
-[x] should we have a shorter list of alias types? (byte, int, uint, float) - done
-[x] reflection support
-[x] syntax for var args
-[x] Do composite literals create a new literal each time (gri thinks yes) (Russ is putting in a change
-    to this effect, essentially)
-[x] comparison operators: can we compare interfaces?
-[x] can we add methods to types defined in another package? (probably not)
-[x] optional semicolons: too complicated and unclear
-[x] anonymous types are written using a type name, which can be a qualified identifier.
-    this might be a problem when referring to such a field using the type name.
-[x] nil and interfaces - can we test for nil, what does it mean, etc.
-[x] talk about underflow/overflow of 2's complement numbers (defined vs not defined).
-[x] change wording on array composite literals: the types are always fixed arrays
-    for array composites
-[x] meaning of nil
-[x] remove "any"
-[x] methods for all types
-[x] should binary <- be at lowest precedence level? when is a send/receive non-blocking? (NO - 9/19/08)
-[x] func literal like a composite type - should probably require the '&' to get address (NO)
-[x] & needed to get a function pointer from a function? (NO - there is the "func" keyword - 9/19/08)
-[x] Conversions:
-	- current situation is messy
-	- 2 (3?) different notations for the same thing
-	- unclear when a type assertion is needed
-	- unclear where conversions can be applied
-	- for type T int; can we say T(3.0) ?
-[x] need for type switch? (or use type assertion with ok in tuple assignment?)
-[x] Is . import implemented / do we still need it?
-[x] Do we allow empty statements? If so, do we allow empty statements after a label?
-    and if so, does a label followed by an empty statement (a semicolon) still denote
-	a for loop that is following, and can break L be used inside it?
-[x] there is some funniness regarding ';' and empty statements and label decls
-[x] cleanup convert() vs T() vs x.(T) - convert() should go away?
-[x] decide if and what to write about evaluation order of composite literal
-    elements (single expressions, (key:value) pairs)
-
+	structs/maps/arrays
+[ ] built-in assert() ("conditional panic") (gri)
 -->
 
+
 <h2>Introduction</h2>
 
 <p>