mirror of
https://github.com/golang/go
synced 2024-11-26 01:07:57 -07:00
conversions are mostly cleaned up; bring the spec in line.
R=gri DELTA=31 (12 added, 18 deleted, 1 changed) OCL=25974 CL=25976
This commit is contained in:
parent
efbb120d8e
commit
ef1b9653dd
@ -3,13 +3,6 @@
|
|||||||
<!--
|
<!--
|
||||||
Biggest open issues:
|
Biggest open issues:
|
||||||
[ ] General iterators
|
[ ] General iterators
|
||||||
[ ] 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) ?
|
|
||||||
- do we need channel conversion (channel direction)
|
|
||||||
[ ] Semantics of type declaration:
|
[ ] Semantics of type declaration:
|
||||||
- creating a new type (status quo), or only a new type name?
|
- creating a new type (status quo), or only a new type name?
|
||||||
- also: declaration type T S; strips methods of S. why/why not?
|
- also: declaration type T S; strips methods of S. why/why not?
|
||||||
@ -21,7 +14,6 @@ Decisions in need of integration into the doc:
|
|||||||
|
|
||||||
|
|
||||||
Todo's:
|
Todo's:
|
||||||
[ ] there is some funny-ness regarding ';' and empty statements and label decls
|
|
||||||
[ ] document illegality of package-external tuple assignments to structs
|
[ ] 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
|
w/ private fields: P.T(1, 2) illegal since same as P.T(a: 1, b: 2) for
|
||||||
a T struct { a b int }.
|
a T struct { a b int }.
|
||||||
@ -46,11 +38,7 @@ Wish list:
|
|||||||
|
|
||||||
|
|
||||||
Smaller issues:
|
Smaller issues:
|
||||||
[ ] need for type switch? (or use type assertion with ok in tuple assignment?)
|
[ ] do we need channel conversion (channel direction)
|
||||||
[ ] Is . import implemented / do we still need it?
|
|
||||||
[ ] 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?
|
|
||||||
|
|
||||||
|
|
||||||
Closed:
|
Closed:
|
||||||
@ -125,6 +113,18 @@ Closed:
|
|||||||
[x] should binary <- be at lowest precedence level? when is a send/receive non-blocking? (NO - 9/19/08)
|
[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] 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] & 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
|
||||||
|
|
||||||
-->
|
-->
|
||||||
|
|
||||||
@ -3643,8 +3643,6 @@ space allocated in the underlying array (for a slice) or map. For a slice
|
|||||||
<h3>Conversions</h3>
|
<h3>Conversions</h3>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
<font color=red>TODO: We need to finalize the details of conversions.</font>
|
|
||||||
<br/>
|
|
||||||
Conversions look like function calls of the form
|
Conversions look like function calls of the form
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
@ -4183,15 +4181,11 @@ The following minimal alignment properties are guaranteed:
|
|||||||
<font color=red>
|
<font color=red>
|
||||||
Implementation accepts only ASCII digits for digits; doc says Unicode.
|
Implementation accepts only ASCII digits for digits; doc says Unicode.
|
||||||
<br/>
|
<br/>
|
||||||
Implementation does not allow p.x where p is the local package name.
|
|
||||||
<br/>
|
|
||||||
Implementation does not honor the restriction on goto statements and targets (no intervening declarations).
|
Implementation does not honor the restriction on goto statements and targets (no intervening declarations).
|
||||||
<br/>
|
<br/>
|
||||||
cap() does not work on maps or chans.
|
cap() does not work on maps or chans.
|
||||||
<br/>
|
<br/>
|
||||||
len() does not work on chans.
|
len() does not work on chans.
|
||||||
<br/>
|
|
||||||
Conversions work for any type; doc says only numeric types and strings.
|
|
||||||
</font>
|
</font>
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user