• griesemer's avatar
    spec: explicitly define notion of "representability" (clarification) · b40831b1
    griesemer authored
    Throughout the spec we use the notion of a constant x being
    representable by a value of type T. While intuitively clear,
    at least for floating-point and complex constants types, the
    concept was not well-defined. In the section on Conversions
    there was an extra rule for floating-point types only and it
    missed the case of floating-point values overflowing to an
    infinity after rounding.
    
    Since the concept is important to Go, and a compiler most
    certainly will have a function to test "representability",
    it seems warranted to define the term explicitly in the spec.
    
    This change introduces a new entry "Representability" under
    the section on "Properties of types and values", and defines
    the term explicitly, together with examples.
    
    The phrase used is "representable by" rather than "representable as"
    because the former use is prevalent in the spec.
    
    Additionally, it clarifies that a floating-point constant
    that overflows to an infinity after rounding is never
    representable by a value of a floating-point type, even though
    infinities are valid values of IEEE floating point types.
    This is required because there are not infinite value constants
    in the language (like there is also no -0.0) and representability
    also matters for constant conversions. This is not a language
    change, and type-checkers have been following this rule before.
    
    The change also introduces links throughout the spec to the new
    section as appropriate and removes duplicate text and examples
    elsewhere (Constants and Conversions sections), leading to
    simplifications in the relevant paragraphs.
    
    Fixes #15389.
    
    Change-Id: I8be0e071552df0f18998ef4c5ef521f64ffe8c44
    Reviewed-on: https://go-review.googlesource.com/57530Reviewed-by: 's avatarRob Pike <r@golang.org>
    Reviewed-by: 's avatarIan Lance Taylor <iant@golang.org>
    Reviewed-by: 's avatarMatthew Dempsky <mdempsky@google.com>
    b40831b1
go_spec.html 199 KB