# Allow ties in floating literals

<!--
Part of the Carbon Language project, under the Apache License v2.0 with LLVM
Exceptions. See /LICENSE for license information.
SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
-->

[Pull request](https://github.com/carbon-language/carbon-lang/pull/866)

<!-- toc -->

## Table of contents

-   [Problem](#problem)
-   [Background](#background)
-   [Proposal](#proposal)
-   [Details](#details)
-   [Rationale based on Carbon's goals](#rationale-based-on-carbons-goals)
-   [Alternatives considered](#alternatives-considered)

<!-- tocstop -->

## Problem

Proposal [#143](https://github.com/carbon-language/carbon-lang/pull/143)
suggested that we do not allow ties in floating-point literals. That is, given a
literal whose value lies exactly half way between two representable values, we
should reject rather than arbitrarily picking one of the two possibilities.

However, the [statistical argument](p0143.md#ties) presented in that proposal
misses an important fact: the distribution of the values that are exactly half
way between representable values includes several values of the form A x
10<sup>B</sup>, where A and B are small integers.

For example, the current rule rejects this very reasonable looking code:

```
var v: f32 = 9.0e9;
```

... because 9 x 10<sup>9</sup> lies exactly half way between the nearest two
representable values of type `f32`, namely 8999999488 and 9000000512. Similar
examples exist for larger floating point types:

```
// Error, half way between two exactly representable values.
var w: f64 = 5.0e22;
```

We would also reject an attempted workaround such as:

```
var v: f32 = 5 * 1.0e22;
```

... because the literal arithmetic would be performed exactly, resulting in the
same tie. A workaround such as

```
var v1: f32 = 5.0e22 + 1.0;
var v2: f32 = 5.0e22 - 1.0;
```

... to request rounding upwards and downwards, respectively, would work.
However, these seem cumbersome and burden the Carbon developer with
floating-point minutiae about which they very likely do not care.

## Background

For background on the ties-to-even rounding rule, see
[this Wikipedia article](https://en.wikipedia.org/wiki/Rounding#Round_half_to_even).
The ties-to-even rule is the default rounding mode specified by ISO 60559 /
IEEE 754.

## Proposal

Instead of rejecting exact ties, we use the default IEEE floating point rounding
mode: we round to even.

## Details

See design changes.

## Rationale based on Carbon's goals

-   [Code that is easy to read, understand, and write](/docs/project/goals.md#code-that-is-easy-to-read-understand-and-write)
    -   This improves the ease of both reading and writing floating-point
        literals that would result in ties.
    -   This improves the language consistency, by performing the same rounding
        when converting literals as is performed by default when converting
        runtime values.
-   [Practical safety and testing mechanisms](/docs/project/goals.md#practical-safety-and-testing-mechanisms)
    -   It is unlikely that making an arbitrary but consistent rounding choice
        will harm safety or program correctness.
-   [Fast and scalable development](/docs/project/goals.md#fast-and-scalable-development)
-   [Modern OS platforms, hardware architectures, and environments](/docs/project/goals.md#modern-os-platforms-hardware-architectures-and-environments)
-   [Interoperability with and migration from existing C++ code](/docs/project/goals.md#interoperability-with-and-migration-from-existing-c-code)
    -   This rule, likely because it is the IEEE default rounding mode, already
        appears to be used by major C++ compilers such as Clang, GCC, MSVC, and
        ICC.

## Alternatives considered

We could round to even only for decimal floating-point literals, and still use
the rule that ties are rejected for hexadecimal floating point. In the latter
case, a tie means that too many digits were specified, and the trailing digits
were exactly `80000...`.

However, because we support arithmetic on literals, forming other literals, this
would mean that whether a literal was originally written in hexadecimal would
form part of its value and thereby part of its type. There would also be
problems with literals produced by arithmetic. The complexity involved here far
outweighs any perceived benefit of diagnosing mistyped literals.