languages/go
languages/go
1
0
Fork 0
mirror of https://github.com/golang/go synced 2024-11-05 18:36:08 +00:00
Code Issues Projects Releases Packages Wiki Activity

clarification of conversion rules for ideal numbers

Browse source 
R=r
DELTA=21  (11 added, 1 deleted, 9 changed)
OCL=17316
CL=17316
This commit is contained in:
Robert Griesemer 2008-10-16 15:03:22 -07:00
parent 3c9b817257
commit 71696ac048
1 changed files with 18 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

26
doc/go_spec.txt
View file

@ -4,7 +4,7 @@ The Go Programming Language Specification (DRAFT)
Robert Griesemer, Rob Pike, Ken Thompson
----
(October 10, 2008)
(October 15, 2008)
This document is a semi-formal specification of the Go systems
@ -60,7 +60,6 @@ Open issues:
[ ] need for type switch? (or use type guard with ok in tuple assignment?)
[ ] do we need anything on package vs file names?
[ ] Do composite literals create a new literal each time (gri thinks yes)
[ ] consider syntactic notation for composite literals to make them parseable w/o type information
[ ] type switch or some form of type test needed
[ ] what is the meaning of typeof()
[ ] at the moment: type T S; strips any methods of S. It probably shouldn't.
@ -73,10 +72,18 @@ Open issues:
functions. This would be in consistency with the declaration of function pointer
variables and the use of '&' to convert methods into function pointers.
[ ] Conversions: can we say: "type T int; T(3.0)" ?
We could allow converting structurally equivalent types into each other this way.
May play together with "type T1 T2" where we give another type name to T2.
[ ] Is . import implemented?
[ ] 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?
[ ] 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
[ ] consider syntactic notation for composite literals to make them parseable w/o type information
(require ()'s in control clauses)
Decisions in need of integration into the doc:
@ -101,6 +108,7 @@ Closed:
[x] & needed to get a function pointer from a function? (NO - there is the "func" keyword - 9/19/08)
-->
Contents
----
@ -1359,18 +1367,20 @@ operators and function invocations on operands. An expression has a value and
a type.
The type of a constant expression may be an ideal number. The type of such expressions
is implicitly converted into the 'expected type' required for the expression.
is implicitly converted into the 'expected numeric type' required for the expression.
The conversion is legal if the (ideal) expression value is a member of the
set represented by the expected type. Otherwise the expression is erroneous.
set represented by the expected numeric type. In all other cases, and specifically
if the expected type is not a numeric type, the expression is erroneous.
For instance, if the expected type is int32, any ideal number
which fits into an int32 without loss of precision can be legally converted.
Along the same lines, a negative ideal integer cannot be converted into a uint
without loss of the sign; such a conversion is illegal.
For instance, if the expected numeric type is a uint32, any ideal number
which fits into a uint32 without loss of precision can be legally converted.
Thus, the values 991, 42.0, and 1e9 are ok, but -1, 3.14, or 1e100 are not.
<!--
TODO(gri) This may be overly constraining. What about "len(a) + c" where
c is an ideal number? Is len(a) of type int, or of an ideal number? Probably
should be ideal number, because for fixed arrays, it is a constant.
-->
If an exceptional condition occurs during the evaluation of an expression
(that is, if the result is not mathematically defined or not in the range