Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: Go 2: Add checked/unchecked arithmetic keywords #29472

Closed
firelizzard18 opened this issue Dec 30, 2018 · 9 comments
Closed

proposal: Go 2: Add checked/unchecked arithmetic keywords #29472

firelizzard18 opened this issue Dec 30, 2018 · 9 comments
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Milestone

Comments

@firelizzard18
Copy link
Contributor

I propose that Go adds checked and unchecked keywords for arithmetic operations that function like those of C#. This is somewhat similar to the Go 2 error handling proposal.

This is related to #19624. If #19624 is accepted, then cases like hash64.go could be handled by wrapping the calculations in an unchecked block, which is a cleaner solution than anything I saw presented on #19624.

Blocks

checked {
  x := a * b
  y := a + b
  z := x^y
}

unchecked {
  x := a * b
  y := a + b
  z := x^y
}

Statements

It would be difficult to allow checked and unchecked to be used on statements without breaking backwards compatibility or making it confusing. The possibilities that occur to me are A) not bothering (only supporting blocks), B) unchecked(a * b), or C) unchecked a * b.

@firelizzard18
Copy link
Contributor Author

To clarify, the keywords would not affect the compilation of function calls. For example, given f(x * y) * z, only the two multiplication operations would be affected. Nothing inside the function call would be affected.

@josharian
Copy link
Contributor

This is a lot of mechanism to add for a relatively small part of the language.

cc @bcmills

@mvdan mvdan added LanguageChange v2 A language change or incompatible library change labels Dec 30, 2018
@bitfield
Copy link

bitfield commented Jan 5, 2019

It sounds like this would be better handled by a library for checked arithmetic.

@bcmills
Copy link
Contributor

bcmills commented Jan 8, 2019

The , ok syntax still seems clearer to me, and doesn't add any new keywords or AST nodes.

checked:

  x := a * b
  y := a + b
  z := x^y

unchecked:

  x, _ := a * b
  y, _ := a + b
  z := x^y

@josharian
Copy link
Contributor

@bcmills is the comma ok approach discussed in another issue? I don’t recall. I have a few comments about it and I’d like to keep the discussion localized.

@bcmills
Copy link
Contributor

bcmills commented Jan 8, 2019

@josharian, the “comma, ok” proposal is #19624.

@firelizzard18
Copy link
Contributor Author

@bcmills If you write every operation as a separate assignment, then it doesn't matter much. But that's not what I would do.

checked, concise:

z := (a * b)^(a + b)
// ...

unchecked, concise:

unchecked {
    z := (a * b)^(a + b)
    // ...
}

unchecked, verbose:

x, _ := a * b
y, _ := a + b
z := x^y
// ...

If the calculation I'm doing is long and complicated, requiring every operation to be a separate assignment would drastically reduce readability.

@bcmills
Copy link
Contributor

bcmills commented Jan 9, 2019

@firelizzard18, under the current draft of #19624 you only need one assignment per expression tree, not one per subexpression. (There is some subtlety around subexpressions that cross function-call boundaries, but that is not applicable here.)

So the unchecked version would be:

z, _ := (a * b)^(a + b)

@ianlancetaylor
Copy link
Contributor

Let's move this discussion into #19624, as an alternative syntax.

(To me the syntax seems to be at the wrong level. I don't expect a block construct to affect the evaluation of expressions within the block.)

(It might be interesting to consider interactions between this and the check error handling proposal described at https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling.md . Could we use check both for error handling and for numeric overflow checks?)

@golang golang locked and limited conversation to collaborators Jan 15, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge LanguageChange Proposal v2 A language change or incompatible library change
Projects
None yet
Development

No branches or pull requests

7 participants