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
In master, we currently have added an optional argument list to `SimpleBaseTypeSyntax` for record primary constructors. However, there is an argument to be made that we should add a new subtype of `BaseTypeSyntax`, something like `PrimaryConstructorTypeSyntax`, to represent these new base type clauses. This was an explicit extension point added in the original design for this very purpose. For either of these designs, GetSymbolInfo will behave consistently: if the `BaseTypeSyntax` has an argument list (either because it's a separate type or because it's a `PrimaryConstructorTypeSyntax`), it will return the constructor symbol or candidates as appropriate. If there are no arguments, then it will return nothing.
4
+
5
+
Pros for keeping the optional argument list on `SimpleBaseTypeSyntax`:
6
+
* The primary constructor arguments feel like an extension to existing nodes, not a totally new node type
7
+
* Existing analyzers/fixers might pick things up right without much modification
8
+
9
+
Pros for extending `BaseTypeSyntax`:
10
+
* This extension point was put in explicitly for this
11
+
* Existing code might be less likely to erroneously use it
12
+
* There was some feeling that it would serve as a more clear delineation for future additions to this syntax (if such C# features ever come to pass)
13
+
14
+
#### Conclusion
15
+
16
+
We lean towards extending `BaseTypeSyntax` in the next preview.
17
+
18
+
### `CompilationOutputFilePaths`
19
+
20
+
The plural when this struct only has one path in it currently felt wrong. Some options for renaming:
21
+
22
+
*`CompilationOutputFileInfo`
23
+
*`CompilationOutputInfo`
24
+
*`CompilationOutputFiles`
25
+
26
+
We leave it up to whoever does the rename to choose among these.
27
+
28
+
### `SolutionInfo.Create`
29
+
30
+
Add `EditorBrowsable(Never)` to the backcompat overload.
31
+
32
+
### `SymbolKind.FunctionPointer`
33
+
34
+
Suffix with `Type` for consistency with the other kinds that are also `TypeKind`s.
35
+
36
+
### `SyntaxFactory.ParseType`
37
+
38
+
The new overload should use `ParseOptions` instead of the specific C#/VB type in both factories.
39
+
Most of the Parse overloads that take a `ParseOptions` here use the non-specific one, and it can be very convenient for IDE APIs here.
40
+
While it is marginally less type-safe, the ergonomic and consistency benefits are a deciding factor.
41
+
42
+
### `WithExpressionSyntax.Receiver`
43
+
44
+
This should be renamed to `Expression` for consistency with other `SyntaxNode`s.
We should reconsider adding multiple overloads, and instead remove the default parameters from the existing overload and introduce a new overload with `transitive` set to `true` to match current behavior.
49
+
This is our standard modus operandi for these scenarios.
50
+
51
+
### `INegatedPatternOperation.NegatedPattern`
52
+
53
+
Rename to just `Pattern`.
54
+
55
+
### `IWithOperation.Value`
56
+
57
+
Rename to `Operand`.
58
+
59
+
### `Renamer.RenameDocumentAsync`
60
+
61
+
Make this and the related structs internal unless we have a partner team ready to consume the API in 16.7. We can make the API public again when someone is ready to consume and validate the API shape.
Debug.Assert(initializerInvocation.HasAnyErrors||constructorInitializer.IsConstructorInitializer(),"Please keep this bound node in sync with BoundNodeExtensions.IsConstructorInitializer.");
0 commit comments