Skip to content

[CS] Some more NFC changes #64149

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
Mar 7, 2023
Merged

Conversation

hamishknight
Copy link
Contributor

Split a couple more changes off #63963

Some clients such as code completion ought to be
able to reference this without pulling in the
entirety of ConstraintSystem.h.
Fill in some nodes that previously weren't being
walked, and bail with `None` if the walk is
terminated, rather than filling the resulting
SolutionApplicationTarget with null pointers.

This method currently isn't called anywhere, but
I'm planning on using it shortly, so this is an
NFC change for now.
@hamishknight
Copy link
Contributor Author

@swift-ci please test

@hamishknight hamishknight merged commit 43f0694 into swiftlang:main Mar 7, 2023
@hamishknight hamishknight deleted the more-nfc-changes branch March 7, 2023 10:49
@AnthonyLatsis
Copy link
Collaborator

@hamishknight Why is SyntacticElementTarget a better name than SolutionApplicationTarget?

@xedin
Copy link
Contributor

xedin commented Mar 7, 2023

Mostly consistency, we have SyntacticElement{ConstraintGenerator, SolutionApplication} and it makes sense to move away from "solution application" because it's a solver target as well.

@AnthonyLatsis
Copy link
Collaborator

it makes sense to move away from "solution application" because it's a solver target as well

I still find SyntacticElementTarget far less idiomatic than the old name. I can’t imagine a lot of people getting even a rough idea of what this currency type exists for by reading the name alone. Both SyntacticElementConstraintGenerator and SyntacticElementSolutionApplication at least express an action by which the purpose of the class can be inferred. Also, isn’t SyntacticElementConstraintGenerator used for stuff inside closures only, unlike SyntacticElementTarget? What do you think of TypeCheckTarget or SyntacticElementTypeCheckTarget?

@xedin
Copy link
Contributor

xedin commented Apr 3, 2023

Also, isn’t SyntacticElementConstraintGenerator used for stuff inside closures only, unlike SyntacticElementTarget?

No, it's not only for closures, it could be used in any supported context which includes function/accessor declarations and if/switch expressions and soon string interpolations.

I personally don't like TypeCheck in the name because I think it's important to maintain distinction that this type is part of the constraint solver.

@AnthonyLatsis
Copy link
Collaborator

Maybe ConstraintSystemTarget then?

@xedin
Copy link
Contributor

xedin commented Apr 13, 2023

I suggested ConstraintSolverTarget before but it seems kind of tautological...

@AnthonyLatsis
Copy link
Collaborator

I suggested ConstraintSolverTarget before but it seems kind of tautological...

Totally works for me as well. There is no ConstraintSolver type but I don’t think that hurts clarity of purpose. I’m not sure I catch on to the tautology though: I see a clear separation between stuff that does the solving (action) and the thing + context data acted upon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants