proposal: net: ParseIP should return an error, like other Parse functions
OrangeTux opened this issue · 4 comments
net.ParseIP
has 1 return value. It doesn't return a value of type error
. Other parse methods like url.Parse
, time.ParseDuration
and net.ParseMAC
return 2 values. One of a specific type, the other is of type error
.
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version
)?
go version go1.7.go version go1.7.4 linux/amd64
What operating system and processor architecture are you using (go env
)?
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/auke/projects/go"
GORACE=""
GOROOT="/usr/lib/go"
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build151269634=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
https://play.golang.org/p/d0K77gxoJe
package main
import (
"fmt"
"net"
)
func main() {
// Trying to parse an invalid MAC address results in an error.
// This is expected behaviour, other Parse methods do also return
// 2 values, like time.ParseDuration or url.Parse.
_, err := net.ParseMAC("invalid")
if er != nil {
fmt.Println(err)
}
// net.ParseIP doesn't follow this signature. It just returns nil
// when parsing failed.
ip := net.ParseIP("invalid")
fmt.Println(ip)
}
What did you expect to see?
I'd expect that net.ParseIP
has this signature:
func ParseIP(s string) (IP, error)
What did you see instead?
func ParseIP(s string) IP
Reasonable but we can't change it now. Marking as go2.
Reasonable but we can't change it now. Marking as go2.
Any idea when go2 will come out?
In current thinking there will never be a Go 2, but this would be a potential net/v2. But there is active discussion on changing the representation of network addresses in the net package over at #46518. This idea should be folded into that discussion. I'm going to close this issue.