You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a primary expression x that is not a package name, the selector expression [...]
My question is... why this distinction? The playground treats a package expression as a struct, in which fields correspond to the exported values of the package. For instance:
There is no reason not to think of m.Set as a Selector in the m struct corresponding to the values of math/bits. Furthermore, doing so solves an ambiguity in the grammar: it's not currently possible at parsing time to decide whether a.b matches the Selector or the QualifiedIdent rule, since both have the exact same syntax. If QualifiedIdent is discarded, then it solves that problem.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
The grammar establishes a distinction between those two:
And the specification clearly states that selectors do not apply to packages:
My question is... why this distinction? The playground treats a package expression as a struct, in which fields correspond to the exported values of the package. For instance:
evaluates to
There is no reason not to think of
m.Set
as a Selector in them
struct corresponding to the values ofmath/bits
. Furthermore, doing so solves an ambiguity in the grammar: it's not currently possible at parsing time to decide whethera.b
matches theSelector
or theQualifiedIdent
rule, since both have the exact same syntax. IfQualifiedIdent
is discarded, then it solves that problem.I'm curious as to why that distinction exists?
Beta Was this translation helpful? Give feedback.
All reactions