Tom Dohrmann
Tom Dohrmann
> [...] or reword it to be more about "don't introduce methods that could clash" [...] than "be a smart pointer". This sounds similar to [C-SMART-PTR](https://rust-lang.github.io/api-guidelines/predictability.html#smart-pointers-do-not-add-inherent-methods-c-smart-ptr).
The book also encourages implementing `Deref` for newtypes: https://doc.rust-lang.org/book/ch19-03-advanced-traits.html?highlight=Deref#using-the-newtype-pattern-to-implement-external-traits-on-external-types
it's possible to get `proc_macro` working outside a macro on nightly by implementing `proc_macro::bridge::server::Server` and using `proc_macro::bridge::client::Client`. wouldn't that solve most of the compatibility issues?
https://github.com/rust-lang/rust/blob/master/src/libproc_macro/bridge/mod.rs it's only meant to be used internally, but you can use it with `#![feature(proc_macro_internals)]`
it's not documented anywhere afaict, so you kinda have to read the source code
> * `POLYGON` -> `geo::Polygon` [`geo::Polygon`](https://docs.rs/geo/0.17.0/geo/struct.Polygon.html) is not equivalent to `POLYGON` as it also handles holes within the bounded area.
You also need to fix the interpreter path.
Perhaps we could approach this from another angle: The [`SliceIndex`](https://doc.rust-lang.org/std/slice/trait.SliceIndex.html) trait is used in the standard library to allow indexing with multiple different types. This was already considered in https://github.com/rust-osdev/x86_64/pull/95#issuecomment-557496537...
Out of curiosity, is there a reason that you're using MTTRs instead of the PAT? This seems like a lot of code for something that has already been superseded.