@@ -69,7 +69,7 @@ enum, mixin, or extension type declaration.
6969<dt >Structural types</dt >
7070<dd >
7171A structural type is a type identified only by the structure of the type. This
72- includes both function types (such as ` int Function(int, int)) ` and record types
72+ includes both function types (such as ` int Function(int, int) ` ) and record types
7373(such as ` ({int x, int y}) ` ).
7474</dd >
7575<dt >Other types</dt >
@@ -136,23 +136,33 @@ example above about the `point` and `pair` variables.) The same is true of
136136parameters in a function type.
137137
138138But what about cases where we know that it's the same field because it's the
139- same variable, and hence the types are not just equal, but are the same? For
140- example, consider
139+ same variable, and hence the types are not just equal, but are more
140+ fundamentally the same? For example, consider
141141``` dart
142- ({int x, int y}) point1 = (x: 1, y: 2);
143- ({int x, int y}) point2 = (x: 3, y: 4);
142+ void f(({String latitude, String longitude}) coordinate) {
143+ print(coordinate.latitude);
144+ print(coordinate.latitude);
145+ }
144146```
145- Because the variables have similar names, human readers are likely to assume
146- that the types are somehow "the same".
147147
148148The problem is that while human readers understand what we mean by "the same",
149- the language spec doesn't define that concept. The two record types are equal,
150- but not any more equal than the types of ` point ` and ` pair ` above. And because
151- there's no definition of the concept, there's no reliable way to confirm whether
152- two identifiers should be considered to refer to the same declaration.
153- 154- In fact, there is no single declaration, there are potentially multiple
155- declarations of the same field (or parameter).
149+ the language spec doesn't define that concept. The type is the same, and hence
150+ equal to itself, but not any more equal than the types of ` point ` and ` pair `
151+ above. And because there's no definition of the concept, there's no reliable way
152+ to confirm whether two identifiers should be considered to refer to the same
153+ declaration.
154+ 155+ And that's the root of the problem. Because this is a structural type there is
156+ no single declaration; there are potentially multiple declarations of the "same"
157+ field (or parameter). When there's an expression of the form ` o.m ` , where the
158+ type of ` o ` is a nominal type, the analyzer can match ` m ` to a single
159+ declaration. When the type of ` o ` is a structural type, the analyzer can't.
160+ 161+ Occurrences are discovered by finding references to a declaration, so in the
162+ case of a structural type the server doesn't have the information it needs. It
163+ _ could_ do something beyond what the language specifies, and it kind of seems
164+ reasonable in this case, but it can't support every case where a user would know
165+ that the fields are the same.
156166
157167So, we're left with a decision: either we don't highlight occurrences of members
158168of structural types, or we have a feature that is inconsistent, highlighting
@@ -163,8 +173,32 @@ Combining the principle that the tools shouldn't misrepresent the language
163173semantics and the principle that the tools should be self-consistent, we decided
164174to not highlight occurrences of members of structural types.
165175
166- ### Navigation
176+ ### Go to declaration
167177
168178The same reasoning that led us to not highlight occurrences of members of
169179structural types led us to not support navigation from references to a member
170180and the declaration(s) of the member.
181+ 182+ ## Multiple elements from a single declaration
183+ 184+ TBD
185+ 186+ ### Fields, getters, and setters
187+ 188+ TBD
189+ 190+ ### Declaring parameters
191+ 192+ TBD
193+ 194+ ## A single element from multiple declarations
195+ 196+ TBD
197+ 198+ ### Augmentations
199+ 200+ TBD
201+ 202+ ### Primary constructors
203+ 204+ TBD
0 commit comments