If you already have your own functions or variables named max, min, or clear in-scope, they will shadow the new built-in functions and your code will continue to use your own version of the functions. No breakage to existing identifiers that match the new function names.
(This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply global functions that can be overridden at other scopes.)
In what way? Overall as a language, identifier shadowing is a feature of the language in nested scopes. Are you saying built-in identifiers (that aren't language keywords) should be treated specially and work differently than user-declared identifiers?
It's terrible, IMO, because every package that has generic words is now a variable name I can't use. A simple example which i find unreasonable:
package main
import (
"fmt"
"path/filepath"
)
func main() {
filepath := filepath.Dir("./")
//filepath.Dir('./") -> This is now a string. Can't use filepath package anymore
fmt.Println(filepath)
}
Now I have to make up variable names because `filepath` will shadow the package. How it this sensible in any shape? Zip just does this better by having @ in front of builtins.
you're complaining that the nomenclature for packages is not differentiated in a way that allows user code to have variable names with the same name as package names
you can still allow this, of course, by aliasing the package import
(This is the same behavior as the append built-in function today, for example. These things in Go are _not_ reserved keywords, they are simply global functions that can be overridden at other scopes.)