Skip to content
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

add ref-return-scope table #3607

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

WalterBright
Copy link
Member

The table with all the permutations should help.

@dlang-bot
Copy link
Contributor

Thanks for your pull request, @WalterBright!

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.

@maxhaton
Copy link
Member

Is there a good reason why these permutations even exist?

@maxhaton
Copy link
Member

A table is good but much better is to enforce a canonical order for each semantic expressible

@WalterBright
Copy link
Member Author

Is there a good reason why these permutations even exist?

Legacy code compatibility.

A table is good but much better is to enforce a canonical order for each semantic expressible

Possibly true, but who wants to update all their code?

@pbackus
Copy link
Contributor

pbackus commented May 17, 2023

iirc the eventual plan is to require that return be written directly before the attribute it modifies (either as return ref or return scope), but disallowing ref return is a breaking change, so for now we're stuck with this awkwardness.

I think the best way to explain this stuff is to start with just ref and scope, and then introduce return as a modifier that can apply to either ref or scope (but not both). Giving all of the possible combinations equal standing in a table (including combinations where the attributes do not interact at all, like scope ref) obscures the underlying semantic rules, and is more likely to make the reader's eyes glaze over than to teach them anything.

Happy to take a crack at writing some documentation for this myself if desired.

@WalterBright
Copy link
Member Author

A table is good but much better is to enforce a [...]

the eventual plan is to require [...]

This PR is documenting the way D behaves now. Initiatives to improve the language should be a separate discussion. The table expresses the meaning better than the prose did.

@WalterBright WalterBright force-pushed the RefReturnScope branch 3 times, most recently from e55e83e to d405df2 Compare May 19, 2023 05:01
spec/function.dd Outdated
$(TABLE2 Combinations of `ref` $(COMMA) `return` and `scope`,
$(THEAD Order, Interpretation)
$(TROW `ref`, $(REFP))
$(TROW `return`, `return`)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return is not an interpretation

Suggested change
$(TROW `return`, `return`)
$(TROW `return`, $(RETURN_SCOPE))

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends on the context. See mtype.buildScopeRef

spec/function.dd Outdated Show resolved Hide resolved
Co-authored-by: Petar Kirov <petar.p.kirov@gmail.com>
spec/function.dd Outdated Show resolved Hide resolved
@dukc
Copy link
Contributor

dukc commented Mar 7, 2024

iirc the eventual plan is to require that return be written directly before the attribute it modifies (either as return ref or return scope), but disallowing ref return is a breaking change, so for now we're stuck with this awkwardness.

Well once we have language editions this can be done. It's otherwise a great plan IMO, but has one problem. How would return be applied to the this reference of a struct or union? void memFun() return ref {/+...+/} does not parse.

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

Successfully merging this pull request may close these issues.

9 participants