From 40d6bb59690e3375a0b78d84f038ea2ab346a593 Mon Sep 17 00:00:00 2001
From: Robert Griesemer <gri@golang.org>
Date: Mon, 20 Apr 2009 15:32:20 -0700
Subject: [PATCH] - 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 | 129 +++++------------------------------------------
1 file changed, 14 insertions(+), 115 deletions(-)
diff --git a/doc/go_spec.html b/doc/go_spec.html
index 486813878b..4c6d26e048 100644
--- a/doc/go_spec.html
+++ b/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>
--
2.30.9