Why not just add the scheme to your string?

func ParseURL(rawurl string) (*url.URL, error) {
	u, err := url.Parse(rawurl)
	if err != nil || u.Scheme != "" {
	    return u, err
	}
	return url.Parse("https://" + rawurl)
}

Why does this needs to be in the standard library? How often does it come up?

Why does this needs to be in the standard library? How often does it come up?

It's comes up every time that a URL is being manipulated in such a way. Maybe indeed a rare use-case but it creates an inconsistency that I cannot reason, if someone can do it, I would love to hear why the behavior is as presented and why a re-parsing function won't be an acceptable solution.

Thanks for your comment

@CommoDor64 what does your proposed SetPath method do? Also why would you need to re-parse anything when making a copy?

@CommoDor64, in your example, the problem is that the definition of URLs is that "example.com/foo" is the same as "foo/bar" - they are both path-only URLs, with no domain at all. Even though example.com looks like a domain, it is not in this case. That is, it is not just a "URL without scheme". It is a "URL without scheme and without domain".

If you want a URL without scheme but with domain, that syntax is "//example.com/foo". Parsing that, setting u.Scheme, and reparsing u.String does work.

The problem here seems to be confusion about the URL syntax as defined by the RFC, not a bug in the Go library, which follows the RFC.

@rsc Thanks for taking the time to reply.
After looking at the RFC https://tools.ietf.org/html/rfc3986 I have to agree completely.

Thanks everyone, I will close the issue

ISTM that the odd thing here is that when there's a URL with a scheme but no host, the string representation makes the first element of the path into the host. Is there something better that it could do in that case? I suspect not.

FWIW, I've had several instances where I needed a Clone() *url.URL method. It's not that hard to write, but I still think, that it would be nice to have in the standard library.