Consistent no-prelude attribute

[Kimundi]

Make name and behavior of the #![no_std] and #![no_implicit_prelude] attributes
consistent by renaming the latter to #![no_prelude] and having it only apply to the current
module.

Optionally add a #[deep(...)] attribute for deeply applying an attribute to each module as
composable replacement for the old behavior.

Rendered

[ghost]

I'm drooling over the idea of #[deep(inline, repr(C), no_mangle, deriving(Clone))] that would apply to all eligible items. Can we make it a thing please?

[sfackler]

#[deep] will be tricky to implement - unless we're going to hardcode the set of supported attributes, there's no way for it to know what locations are eligible for each attribute. It could stick all of them everywhere, but it'd have to be a bit careful to avoid tripping the unused attr lint.

[pythonesque]

Wow, #[deep] sounds great (I realize that wasn't the main thrust of the RFC).

[reem]

@sfackler we could just mark #[deep]-applied attributes as #[allow(unused_attr)].

[sfackler]

You can't attach attributes to attributes :P

[reem]

I guess #[cfg_attr] is dark magic.

[emberian]

👍 straightforward consistency win. I feel uncomfortable with #[deep], though. I have notes about a #[cascade] syntax extensions in a notebook somewhere, that does something similar, but more flexible/extensible than this (this would be expressed in it as #[cascade(mod, no_prelude)]).

[emberian]

@brson: we should fast-track this.

[aturon]

I think this is a fine change (no opinion about deep). My sole hesitation is that we'd like to make it possible to provide custom preludes, which would likely subsume the #![no_implicit_prelude] directive.

I don't think that we plan on stabilizing these attributes (certainly not for alpha) so we have a bit of time.

OTOH I'm happy to roll this out now as a clear improvement on the status quo, and then remove it if we can get custom preludes in quickly enough.

[Kimundi]

I update the RFC with the #[deep] attribute removed for now - its not really neccessary, and complicates the otherwise very simple proposal.

@aturon: I'd be perfectly happy with accepting this even if a more general solution might appear any day - it would be an improvement either way.

[aturon]

Thanks @Kimundi! The core team plans to meet early tomorrow and I'll make sure this is covered (I suspect it will be accepted immediately.) Sorry again about the delay.

[aturon]

@Kimundi I was able to reach enough of the core team to go ahead and move forward with this. As we discussed above, there's little reason not to go ahead and make this improvement even if it will be subsumed by some later mechanism. Thanks for writing the RFC!

Tracking issue