Remove the plugin?

[SimonSapin]

The string_cache_plugin crate provides atom! and ns! syntax extension that turns static atoms into their interned representation at compile time. In #95 I’ve introduced an alternative: the string_cache crate has a build script that generates a giant (couple thousand lines) macro_rules! macro:

https://gist.github.com/anonymous/1f4638851d6e3c8f1975#file-ns_atom_macros_without_plugin-rs-L326

It’s ugly, but it runs on stable Rust while the plugin breaks and needs to be updated when compile internals change.

I’m tempted to remove the plugin and change every downstream user to use the macro. Or is there still a reason to prefer the plugin? CC @Manishearth @pcwalton @frewsxcv

[asajeffrey]

Can we do case-insensitive atoms without expanding out the O(2^n) cases?

[frewsxcv]

I don't feel strongly about either direction.

[SimonSapin]

Not without a compiler plugin, I don’t think. We could also remove case-insensitivity (which is only in ns!, not atom!) and only accept all-lowercase and all-uppercase namespace prefixes.

[asajeffrey]

This only impacts our own code -- what would happen if we made it a compile-time error for ns!(...) to be called with anything other than a lower-case string?

[SimonSapin]

Or all-lowercase only! I’m ok with that. It’s a breaking change, but easy to fix.

And while we’re making breaking changes, should we remove Atom::as_slice (use Deref or AsRef impls instead) and replace Atom::from_slice with a std::convert::From impl?

[asajeffrey]

These changes sound sensible, and in line with DOMString::from(string) and String::from(domstring). This is a separate issue though.