Core::primitive doesn't work

language design
1

This module reexports the primitive types to allow usage that is not possibly shadowed by other declared types.

[…]

We also used ::core instead of core, because core can be shadowed, too. Paths, starting with ::, are searched in the extern prelude since Edition 2018.

Except that you can actually still shadow ::core: [playground]

extern crate self as core;
const _: ::core::prelude::bool = true;
// ERROR

It probably should be at least a warning if you ever shadow ::core or ::std, if not deny by default so you have to acknowledge that things are going to break.

10 Likes
2

Hopefully one day we will have macros with proper hygiene, and arcane workarounds like ::core will no longer be necessary.

4 Likes
3

I remember I used to go "full paranoid" and re-export core or whatnot from the special hidden module of my crate, and then use $crate::__that_module::core::... paths. But since non-function-like/bang proc-macros don't get that luxury, I've had to settle with the practical stance that if a user shadows core/alloc/std, then it's on them.

So yeah, big + for there being some deny-or-warn-by-default lint, warning of not only macros being susceptible of breaking if shadowing these, but also even of certain macros losing any semblant of soundness in such a scenario.

Indeed, shadowing core/alloc/std nowadays is, conceptually, an unsafe operation, since unsafe-using macros may be relying on type paths such as ::core::mem::ManuallyDrop::new(...) doing the "expected thing" (since the only other possible stance here would be to declare all of these macros unsound).

Which is why I even think a warn-by-default would be too lenient: it ought to be a deny-by-default, even.

Aside: I would suggest renaming the title of this thread, poor ::core::primitive does not deserve that much criticism; it's just a module re-exporting the primitive types. Its docs justify its existence with some macro lack-of-hygiene good practices, and said practices have limits such as ::{core/alloc/std}-shadowing. What about using, as thread title: "lint against shadowing ::{core,alloc,std}"?

6 Likes
4

Wait. Don't macros have proper hygiene?

1 Like
5

The only stable hygiene is currently "semitransparent" which is equal to proper hygiene for things like variables, but is not hygienic at all for items (with the exception of $crate, which is fully hygienic).

8 Likes