Use keyword crate to define crates: pub crate std;

[liigo]

After #12017 (extern crate x;) is landed, we may reuse the new keyword crate to define crates:

pub crate std;

We can always place docs and attributes on top of the crate's definition. As a result, the inner- (or outer- someone maybe calls it) docs and attributes, will forever gone.

src/libstd/lib.rs:

/// docs and attributes go here
#[crate_type = "rlib"]
pub crate std;

[pnkfelix]

To my knowledge, the purpose of a declaration like extern crate x (which might end up being shortened to just crate x, I do not yet know), is to link to a crate that has been defined elsewhere. It does not serve as the definition for the crate itself.

I would not want to copy all of the currently-inner attributes for a crate (which currently appear once, in the file that is defining the crate itself) on to each site where that crate is being linked (as such sites appear many times, on each other application or library that is linking to the crate).

Is there hidden in your proposal an implicit request that the declaration crate x not be a form to link to an external crate, but is instead, what, some sort of header that one is supposed to put at the top of the crate? Because otherwise, I do not understand what it is you are suggesting.

[huonw]

I saw someone suggest the same thing a few days ago: use crate; and mod; to be points for attaching inner doc comments, e.g.:

/// Docs go here
#[crate_id="std"]
#[crate_type="rlib"]
crate;

mod foo {
    /// Docs go here
    #[macro_escape]
    mod;
}

[pnkfelix]

Wow, are inner attributes really that distasteful to everyone else?

This suggestion seems like a step backwards to me, but I don't have the same reaction towards inner attributes, I guess.

[huonw]

(FWIW, I wasn't arguing for or against this change, I was just noting another very similar suggestion; I'm quite happy with inner attributes... if they weren't just a ; away from outer ones, but that's covered by #2569.)

[liigo]

2014年2月8日 下午8:12于 "Felix S Klock II" [email protected]写道：

To my knowledge, the purpose of a declaration like extern crate x (which
might end up being shortened to just crate x, I do not yet know), is to
link to a crate that has been defined elsewhere. It does not serve as the
definition for the crate itself.

I would not want to copy all of the currently-inner attributes for a
crate (which currently appear once, in the file that is defining the crate
itself) on to each site where that crate is being linked (as such sites
appear many times, on each other application or library that is linking to
the crate).

Is there hidden in your proposal an implicit request that the declaration
crate x not be a form to link to an external crate, but is instead, what,
some sort of header that one is supposed to put at the top of the crate?
Because otherwise, I do not understand what it is you are suggesting.

To explicitly define a crate, as we define a function, and explicitly
attach docs and attrs to that crate, in the same way attach to a function.

It is define a crate, not declare to link it. pub crate std; is need to
write only once, in file src/libstd/lib.rs

—
Reply to this email directly or view it on GitHub.

[nikomatsakis]

I think the idea of attaching attributes to the keyword crate was my suggestion (perhaps others too). To be honest, I like inner attributes too, it was just a thought as to a way to simplify syntax if we wanted that. That said, I want to keep inner doc comments, whatever we do (if it were up to me, I'd remove outer ones ;)

[liigo]

Too many doc-comment styles currently
2014年2月10日 下午7:43于 "Niko Matsakis" [email protected]写道：

I think the idea of attaching attributes to the keyword crate was my
suggestion (perhaps others too). To be honest, I like inner attributes too,
it was just a thought as to a way to simplify syntax if we wanted that.
That said, I want to keep inner doc comments, whatever we do (if it were up
to me, I'd remove outer ones ;)

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12107#issuecomment-34622826
.

[alexcrichton]

Visiting for triage, language changes such as this now require going through the formal RFC process, so I'm going to close this. If you'd still like to pursue this, feel free to open an RFC!

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#307