ඞ character in generated type is not keyboard friendly

[azriel91]

Heya, I'm experimenting using this crate (it's magic!), and noticed that implementation crates need to import my_lib::TheTraitඞItem, defined here:

https://github.com/danielhenrymantilla/nougat.rs/blob/7ddcdefd416c1538c0fa578e74e2f9eeca1b1e5f/src/proc_macros/mod.rs#L71

It also means the library crate needs to export it.

Given I can't type that character (though my editor helpfully generates the import), could it be changed to a typable character, or even no character? (considering collisions, instinctively TheTraitItem doesn't tend to show up in the way I name types, but that's me)

[danielhenrymantilla]

Heh, I reckon this hard-to-type character may not suit everybody, but I'm currently trying a design where it's there on purpose / by design 😅: I just recently replaced __ with ඞ when I noticed mentions of people hard-coding the generated path.

But I won't force too much in this direction, if my strategy ends up being too problematic I'll backtrack and go back to __, I think.

But let me phrase why I went for that choice:

• the main reason is that I'd like to keep the actual "hack" / workaround used to achieve GAT-ness as hidden as possible from the API of users, to hide the nitty-gritty details; mostly to give myself a bit more of lenience / freedom in what I could change without it being a breaking change (e.g., I had to go for __ -> ඞ being a breaking change precisely because of __ being "too public").

• related to this, a design goal for future versions of nougat is to be able to "turn the crate off" and make it become a bunch of no-op / identity macros, through some generic-associated-types feature. That way, it will make the transition to proper gats smoother: anybody using nightly or future stable rust could enable the feature, and get rid of nougat's own logic (in compile-time cost) and suboptimal diagnostics. Then, a direct user of nougat could just remove the #[gat]s and the Gat!s. If people circumvent the abstraction boundary, then this wouldn't be possible.

But maybe I'm being too optimistic, so I'm mentally ready to let reality tell me wrong and to change this 😅.

But until then, let's try to fight a bit more for the abstraction API:

1st point: Gat proxy macros don't support use imports

and noticed that implementation crates need to import my_lib::TheTraitඞItem

This is, thus, imho, the actual issue: I've forgotten to offer an abstraction / macro layer over this operation! (all my tests implemented the gat-trait in the very module where it was defined, or using full paths in the impl line 🤦)

A simple workaround would be:

#[gat(Item)]
// pub /* supporting reëxports will be important too! */
use path::too::TheTrait;

and this would take care of importing the assoc-item traits as well.

However, this, and the whole explanation for ඞ, would need to be way better documented than it is now:

2nd point: document these things more extensively and with higher visibility (gotchas of the crate)