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

allow multiple mod or extern mod inclusions per stmt #11819

Closed
thestinger opened this issue Jan 26, 2014 · 14 comments
Closed

allow multiple mod or extern mod inclusions per stmt #11819

thestinger opened this issue Jan 26, 2014 · 14 comments

Comments

@thestinger
Copy link
Contributor

Either mod foo, bar, baz or mod {foo, bar, baz}. I would prefer leaving off the braces as they would be fully redundant without adding clarity.

@adrientetar
Copy link
Contributor

Braces are already in place for multiple use statements so we will need consistency I think.

@thestinger
Copy link
Contributor Author

Using a noisier syntax with redundancy for the sake of consistency doesn't make a whole lot of sense to me. If it's not providing additional clarity, then why have it? I'm not sure what the rationale was for removing the cleaner syntax for use statements. If it's not going to look clean... then I'd rather not have this feature at all.

@flaper87
Copy link
Contributor

I kinda agree with @thestinger here. I'm always leaning towards consistency, however, I don't think it makes a whole lot of sense in this case. I'd vote for mod foo, bar, baz.

If this makes sense to people and we want to go down that road, I'd love to work on a fix for this myself.

@huonw
Copy link
Member

huonw commented Jan 26, 2014

Attributes like /** docs */ mod foo, bar; would either need to be an error under this scheme; or be shared across all modules.

@alexcrichton
Copy link
Member

I think that @huonw has a good point about multiple module declarations and documentation. I would be more in favor of adding extern crate {foo, bar, baz}; to the language than mod foo, bar, baz;

@huonw
Copy link
Member

huonw commented Jan 27, 2014

extern crate foo, bar, baz; can also have attributes. (I don't think documentation was a very good example, since the most common & sensible thing to do is to have the documentation inside the module itself.)

@flaper87
Copy link
Contributor

I'm still leaning towards extern crate foo, bar, baz I think it is syntactically correct because the crates listed there don't share a namespace as opposed to use std::libc::{...}

If this sounds like something for 1.0, i could be done as part of #9880 I'd be happy to work on this since I already signed up for the other one.

@huonw
Copy link
Member

huonw commented Jan 27, 2014

Another thing with crates is the extern crate foo = "something#foo;1.0"; syntax; would that become extern crate foo = "stuff", bar = "other#stuff", baz = "even_more#stuff"?

@ben0x539
Copy link
Contributor

fwiw, since it took me some time to find it again, use-statements bringing multiple top-level non-pathy identifiers into scope via a braced list happened in #10806.

@sinistersnare
Copy link
Contributor

Was about to create an issue of this when i remembered that this was created!

I totally think we should do this, and am on the fence about keeping consistency with the use statement by using curly brackets.

extern crate {crate1, crate2, crate3};
extern crate {firstcrate = "crate1", secondcrate = "crate2"};

@liigo
Copy link
Contributor

liigo commented Feb 25, 2014

+1, like it
2014年2月25日 上午4:39于 "Davis Silverman" notifications@github.com写道:

Was about to create an issue of this when i remembered that this was
created!

I totally think we should do this, and am on the fence about keeping
consistency with the use statement by using curly brackets.

extern crate {crate1, crate2, crate3};extern crate {firstcrate = "crate1", secondcrate = "crate2"};


Reply to this email directly or view it on GitHubhttps://github.com//issues/11819#issuecomment-35932922
.

@sinistersnare
Copy link
Contributor

I think that this proposal should go through the RFC process. What does everyone think?

@pnkfelix
Copy link
Member

pnkfelix commented Jul 1, 2014

Closing: @sinistersnare is correct, a change like this needs to go through the RFC process that we have instated: https://github.com/rust-lang/rfcs

@pnkfelix pnkfelix closed this as completed Jul 1, 2014
@sinistersnare
Copy link
Contributor

I will see if i can write something up for discussion.

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 25, 2022
…tors/code/minimist-1.2.6, r=Veykril

Bump minimist from 1.2.5 to 1.2.6 in /editors/code

Bumps [minimist](https://github.com/substack/minimist) from 1.2.5 to 1.2.6.
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/substack/minimist/commit/7efb22a518b53b06f5b02a1038a88bd6290c2846"><code>7efb22a</code></a> 1.2.6</li>
<li><a href="https://github.com/substack/minimist/commit/ef88b9325f77b5ee643ccfc97e2ebda577e4c4e2"><code>ef88b93</code></a> security notice for additional prototype pollution issue</li>
<li><a href="https://github.com/substack/minimist/commit/c2b981977fa834b223b408cfb860f933c9811e4d"><code>c2b9819</code></a> isConstructorOrProto adapted from PR</li>
<li><a href="https://github.com/substack/minimist/commit/bc8ecee43875261f4f17eb20b1243d3ed15e70eb"><code>bc8ecee</code></a> test from prototype pollution PR</li>
<li>See full diff in <a href="https://github.com/substack/minimist/compare/1.2.5...1.2.6">compare view</a></li>
</ul>
</details>
<br />

[![Dependabot compatibility score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=minimist&package-manager=npm_and_yarn&previous-version=1.2.5&new-version=1.2.6)](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting ``@dependabot` rebase`.

[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)

---

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- ``@dependabot` rebase` will rebase this PR
- ``@dependabot` recreate` will recreate this PR, overwriting any edits that have been made to it
- ``@dependabot` merge` will merge this PR after your CI passes on it
- ``@dependabot` squash and merge` will squash and merge this PR after your CI passes on it
- ``@dependabot` cancel merge` will cancel a previously requested merge and block automerging
- ``@dependabot` reopen` will reopen this PR if it is closed
- ``@dependabot` close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- ``@dependabot` ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- ``@dependabot` use these labels` will set the current labels as the default for future PRs for this repo and language
- ``@dependabot` use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- ``@dependabot` use these assignees` will set the current assignees as the default for future PRs for this repo and language
- ``@dependabot` use this milestone` will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/rust-analyzer/rust-analyzer/network/alerts).

</details>
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

No branches or pull requests

9 participants