4 ms·

So I guess with new builtin functions we will be breaking backwards compatibility?

racingmars 3y ago
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.)
- metaltyphoon 3y ago
  Lets be honest, its a terrible choice
  - racingmars 3y ago
    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 3y ago
      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 3y ago
        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?
- throwawaygo 3y ago
  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.

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

metaltyphoon 3y ago
Lets be honest, its a terrible choice
- racingmars 3y ago
  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 3y ago
    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 3y ago
      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?
throwawaygo 3y ago
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.