mirror of
https://github.com/golang/go
synced 2024-11-22 00:44:39 -07:00
- 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
This commit is contained in:
parent
0dd5be48aa
commit
40d6bb5969
129
doc/go_spec.html
129
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>
|
||||
|
Loading…
Reference in New Issue
Block a user