Now, the qualified selector form is "aPkg.Exported".
The form is the same as object selector, "aObj.Property".
Sometimes, it is not very clear for code readers to recognize
the first parts of such slectors is an import or an object.
So, I think the C++ way "aPkg::Exported" is more readable.
Let's extend the C++ denotion a bit, by using the "::foo"
to represent the identifer "foo" declared at the top
level of the current package, and using ":bar" to
represent the innermost declared identifer "bar".
The notation ":bar" is only meaningful when it is used
as a target value in a variable declaration (see below).
Suppose we can declare scope identifers, here is
an example to show the above ideas:
var a = 1
func f() {
var a = 2
{
scope x
var a = 3
{
println(::a, x:a, a, :a) // 1 2 3 3
}
}
}
(The above description is just to make the following
described new variable redeclaration syntax look natural.
In fact ":id" may only be allowed to be used as L-values
in variable declarations below.)
We all know that, although short variable declarations (x, y := a, b)
do solve some problems, they also brings some new ones.
The new problems include:
1. break the "one solution to do something" principle in Go.
Short declarations overlap too much with standard declarations in
functionalities.
2. short declarations brings some confusions to Go programmers, in
particular to new gophers.
* It is not very clear to get which identifiers are new declared
and which are redeclared at the first glance.
* Almost every gophers ever dropped in the famous variable shadowing
trap caused by using short declarations. A real world example:
https://github.com/Azure/go-ntlmssp/pull/24
* Not all L-values suitable to act as target values are allowed
be show up as the target values in short declarations.
https://github.com/golang/go/issues/30318
Recently, I just got an idea which is inspired from this thread:
https://github.com/golang/go/issues/377.
The idea (almost) removes short declarations and also solves
the problems short declarations solved. More importantly,
it doesn't bring the problems short declarations brought.
However, my perception might be limited. There might be
flaws in this idea, and the idea might bring new problems.
So any criticisms are welcome.
The following code shows the logic of the idea:
package bar
func foo() {
var x, err = f()
...
// Here ":err" means the "err" declared above.
var y, z, :err = g()
...
{
// The ":err" also means the "err" declared above.
var w, :err = h()
...
// This "err" is a new declared one.
var m, n, err = k()
...
}
}
Selectors, dereferences, element indexing, and the above
mentioned ":id" forms are allowed to show up as target values
in a variable declaration, as long as there is at least one
pure identifier in the declaration. The pure identifiers represent
new declared variables. The new variables are initialized,
others are re-assigned with new values.
type T struct {
i *int
s []int
}
var t T
var p = new(int)
func bar() {
// "err" is new declared, others are not.
var *p, t.i, t.s[1], :p, err = 1, p, 2, t.i, errors.New("bar")
// *:p is not valid. In other words, :id must show up independently.
...
}
The := redeclaration syntax should be kept ONLY in the
simple statements in control flows, just for aesthetics reason.
In other words, "... := ..." is totally a shorthand of
"var ... = ..." in the simple statements in control flows.
if a, b := c, d; a {
}
//<=>
if var a, b = c, d; a { // some ugly
}
// However, personally, I also think the ugly version is acceptable.
The idea should be Go 1 compatible. What I mean here is
the above proposed new redeclartion syntax may coexist with
the current standard and short variable declarations.
And it is easy to let "go fix" translate short variable
declarations into the above proposed new syntax form.
The short declarations in the simple statements
in control flows don't need to be translated.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/3073e599-4c37-4aa7-a78a-9685eeb54252%40googlegroups.com.
