4 ms·
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 languag
by 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 agoIt'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 agoyou'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?