fix Issue 19097 - Extend Return Scope Semantics

[WalterBright]

See enhancement request for details.

To keep this PR from being too complex, I didn't do return inference. That'll be on a follow-on later.

This will be necessary to get Phobos to compile with -dip1000. Hence the Vision label.

[dlang-bot]

Thanks for your pull request, @WalterBright!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	19097	enhancement	Extend Return Scope Semantics

Testing this PR locally

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

dub fetch digger
dub run digger -- build "master + dmd#8504"

[wilzbach]

auto-tester failures are related to the Phobos modules we check with -dip1000.
Not sure about a good solution, but dlang/phobos#6638 would help for now (and unblock this PR).

[WalterBright]

Curiously, the autotester was green last night.

[wilzbach]

Yes, we re-enabled -dip1000 testing for the auto-tester today (at least for all the modules which are part of the dip1000.mak).

[JinShil]

I can't understanding anything in this PR because there is no spec or other documentation describing the semantics.

[WalterBright]

no documentation

https://issues.dlang.org/show_bug.cgi?id=19097

[JinShil]

Not good enough. The appropriate place for documenting the semantics of the language is https://github.com/dlang/dlang.org/tree/master/spec

[WalterBright]

It has all that's needed to understand this PR. If you have any other questions about how/why, please post here or (better) on the bugzilla page.

[JinShil]

There needs to be a spec update accompanying each of these DIP1000-related PRs (e.g #8408, #8346), not only for the review process, but also so users know how to leverage these features. Furthermore, these features cannot be evaluated in isolation; they need to be evaluated in the context of the existing language, and all of the prior PRs that were merged without any accompanying documentation, so the hole is just getting deeper.

Users are only going to encounter confusion and uncertainty without these semantics documented in the spec. They can't even file bugs with any confidence, because they don't have a spec to compare their symptoms with and instead resort to "Is this a bug?", "What's the status of @safe/DIP1000?" posts on the forum. Even when attempting to answer such questions, veterans of the language are just resorting to educated guesses.

[thewilsonator]

This is now documented in dlang/dlang.org#2453, I'm still very disappointed with the way this has been handled.

[thewilsonator]

Auto-merge toggled on

[JinShil]

FWIW, I think this was merged prematurely. My objection wasn't just about the documentation. We needed the documentation in order to properly review this PR. After spending some time studying what @WalterBright was proposing, I offered an alternative in https://issues.dlang.org/show_bug.cgi?id=19097 so users don't have to rely on convention to get the result, but my suggestion was never acknowledged or addressed. Others brought up issues on the forum, but they also were never adequately addressed.

I suppose it's all moot now, but this can serve as a good example of what not to do in the future. I fear that having to infer return based on convention is not going to end well for D in the long run.