Robust crate names (alternative to #61)

[dvdplm]

An alternative to #61

The difference here is that the crate Idents are static items, still created using @bkchr's https://github.com/bkchr/proc-macro-crate and wrapped in a Lazy, and then wrapped in a IdentHelper that implements quote::ToTokens for ergonomic use in the derive macro.

[bkchr]

But why? :D

[dvdplm]

But why? :D

It's a bit more ergonomic to use a global imo. After all, the crate name is constant and in #61 you have to pass around the crate name to all method calls which to me is a bit boiler plate-ey.

Why do you think this is worse, what are the downsides? :)

[Robbepop]

It's a bit more ergonomic to use a global imo. After all, the crate name is constant and in #61 you have to pass around the crate name to all method calls which to me is a bit boiler plate-ey.

I can totally understand your argument and I think there is absolutely nothing wrong with your opinion about this.
To me it just feels odd having global state in a program that does not necessarily need it - maybe that's me being religious.
Another minor downside is the extraneous once_cell dependency.

[ascjones]

The derive code has become more complicated and could do with some refactoring, but personally I would prefer moving towards something like the 2 step parse -> Intermediate Representation -> expand style, and have the crate names defined as part of the IR.

I did consider doing some refactoring as part of #61 but decided passing to the arguments to the functions wasn't so bad.

[ascjones]

I have a (probably irrational) aversion to global singletons unless absolutely necessary, though there is nothing wrong with them per se they are often a code smell.

[dvdplm]

Conceptually these aren't really globals of the bad kind though; they are constants and not really "state" (and obviously not mutable state).
Imagine a parallel universe where an Ident as actually a &'static str and proc-macro-crate::crate_name was a const fn, wouldn't it be more natural to have const SCALE_INFO: Ident = proc-macro-crate::crate_name("scale-info").expect("wut?!");? The crate name used is a value that does not vary, it's constant.

[ascjones]

I understand your point, but like I said it's irrational 😁

[dvdplm]

decided passing to the arguments to the functions wasn't so bad.

It's obviously a minor point and I won't make a fuss if the consensus is this PR is not good.

My counter argument here is that function signatures carry semantic value and that going beyond three arguments whose meaning is obvious from context is best avoided when possible. In #61 we go from 3 to 5 and the newcomers are technical in nature and has little to do with what the function actually does, in other words, they're noise. So there's one code smell against the other.

I like your idea of having an explicit "expand" phase where technical details such as this one can roam free.

[ascjones]

I agree the passing around of the args is less than ideal, this derive code is in need of some love

[ascjones]

See #63