Skip to content

go: Dividing a floating-point number literal by an integer should be an error #5728

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

Closed
hajimehoshi opened this issue Jun 18, 2013 · 4 comments

Comments

@hajimehoshi
Copy link
Member

Before filing a bug, please check whether it has been fixed since the
latest release. Search the issue tracker and check that you're running the
latest version of Go:

Run "go version" and compare against
http://golang.org/doc/devel/release.html  If a newer version of Go exists,
install it and retry what you did to reproduce the problem.

Thanks.

What steps will reproduce the problem?
If possible, include a link to a program on play.golang.org.
1. Compile the below code:

package main

import (
        "fmt"
)

func main() {
        fmt.Printf("%v\n", 1.0 / 2)
        i := 2
        fmt.Printf("%v\n", 1.0 / i)
}

What is the expected output?
(Compile error)

What do you see instead?
0.5
0

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
Linux

Which version are you using?  (run 'go version')
go version go1.1 linux/amd64

Please provide any additional information below.
I understood the reason but it is surprising. If I use the number literal '1.1' instead
of '1.0', a compile error happens.  This looks inconsistent to me.  I think it is better
to raise an error when dividing a floating-point number literal by an integer.
@hajimehoshi
Copy link
Member Author

Comment 1:

http://play.golang.org/p/ku8h8dwxei

@cznic
Copy link
Contributor

cznic commented Jun 18, 2013

Comment 2:

The output is correct, please check the language specification about how are constants,
and expression involving constants, treated. BTW, that handling is IMO pretty consistent.
#WorkingAsIntended

@hajimehoshi
Copy link
Member Author

Comment 3:

Thanks.  I need to be familiar with the notion of 'untyped' values.

@DanielMorsing
Copy link
Contributor

Comment 4:

This is consequence of constant conversion.
The relevant rule of the spec is in the binary op section: "Except for shift operations,
if one operand is an untyped constant and the other operand is not, the constant is
converted to the type of the other operand."

Status changed to WorkingAsIntended.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants