Check nested func

[thewilsonator]

No description provided.

[dlang-bot]

Thanks for your pull request and interest in making D better, @thewilsonator! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16942"

[dkorpel]

I'm not a fan of shuffling between between *sem.d files. We have a clear goal for moving semantic routines to *sem.d files, so the AST definition is standalone. I'd defer movement between sem files to reduce disruption.

It's not like expressionsem, funcsem, dsymbolsem etc. are standalone packages. One type of semantic can trigger other types of semantic by design. Just because most uses are in expressionsem.d doesn't mean a function needs to reside there. I fear almost everything is going to end up there that way, and it's already nearing 20000 lines.

[thewilsonator]

I'm not particularly either, but this function is only called from expressionsem.d, hence making it private. If you feel strongly about it I can axe the third commit (or move it to a separate PR), but we should keep the first two commits.

[dkorpel]

I'm not particularly either, but this function is only called from expressionsem.d, hence making it private.

I've made functions private just because I could before, only to later make them public again because it turned out it was private by happenstance: all uses happened to be in the same module now, but with later fixes and improvements, the private function needed to be called from different modules. Making things private shouldn't be a goal of its own.

If you feel strongly about it I can axe the third commit (or move it to a separate PR)

I see complaints that PRs / feature branches (e.g. Timon's tuple branch) need to be constantly rebased because of code movement, so it is causing disruption. Now I think that pill can be swallowed if we're sure it should to happen, and we committed to separating AST nodes from semantic routines.

Moving from funcsem.d to expressionsem.d might be beneficial in this case, but is it the final destination? Imagine someone rebasing their funcsem changes onto expressionsem after the move, and then we decide "you know what, expressionsem is getting rather large, let's split it up", and then they have to rebase their code again. That is just too much.

I suggest keeping the first two commits indeed.