It's not wrong to say that they shouldn't be "traditional" lang items, where the language can add special powers to the type (as is
But it's (IMHO) incorrect to argue that
Option shouldn't be a lang item in that you say "hey compiler, here's my
Option type, that I use for all the other times you expect to see
#[lang_here_it_is = "Option"] enum Option is strictly better than the status quo of a hardcoded path. Now, if I'm implementing my own core, I can provide my own implementation that's not called
Option and isn't at
::core::option::Option, because I can tell the compiler where it is.
It's fine to say that
Option should be a weaker lang item than
Box is. But if the language knows about it (and it does, because it's used in the desugaring of
for), then it should be a lang item, because the item is part of the language.
It can (and probably should) be a weaker lang item where the compiler only has the power to know the path and check that the type has the correct shape, and not to create special behaviors. But it's still a lang item, even if the only lang item part of it, is the language using the plain old surface Rust item.
Or IOW: "lang item" doesn't mean "I'm an item that has special language-defined behavior different from my surface appearance," it means "I'm an item that the language knows about."
You can argue that these should be made more distinct. (I agree!) However,
Option clearly is the second type of lang item, and nobody (that I know of) wants it to also be the first.