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

probably

> * `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.