[racingmars]

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.)

[throwawaygo]

You’re right. Backwards unfriendly is maybe a better way to say it.

min and max are common variable names so depending on the version of go and the scope you should expect min and max to mean different things.

No reason these functions couldn’t have been part of the stdlib.

[metaltyphoon]

Lets be honest, its a terrible choice

[racingmars]

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?

[metaltyphoon]

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.

[preseinger]

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

but needing to do this is "terrible"

is that correct?