It would be convenient if proc-macro can be used.
However, using proc-macro might need internal features to be exported as (semi-)public API.
Assume iri-string depends on iri-string-macros crate, which is proc macro crate.
iri-string-macros should have access to validators but it obviously cannot depend on iri-string, some core functionalities should be provided as another dependencies (say iri-string-core).
For iri!() macro, iri-string-core will only need to expose validate_iri(), but it obviously relies on other sub parsers, and I don't want to guarantee anything about their API stability.
If the parsers are hidden inside iri-string-core, iri-string cannot access them so they need to have duplicate logic in iri-string and iri-string-core, which is obviously bad for maintainability.
Opting out semver by using =x.y.z anytime for iri-string-core will be an option, but it may be annoying to keep such a code clean.
For example, exporting everything as pub item prevents compiler from checking unused items.
The current situation doesn't look great for providing compile-time complex validation for dedicated types.
It would be convenient if proc-macro can be used.
template::context::Context#50 (derive macro)iri!("https://example.com/")(function-like macro)However, using proc-macro might need internal features to be exported as (semi-)public API.
Assume
iri-stringdepends oniri-string-macroscrate, which is proc macro crate.iri-string-macrosshould have access to validators but it obviously cannot depend oniri-string, some core functionalities should be provided as another dependencies (sayiri-string-core).For
iri!()macro,iri-string-corewill only need to exposevalidate_iri(), but it obviously relies on other sub parsers, and I don't want to guarantee anything about their API stability.If the parsers are hidden inside
iri-string-core,iri-stringcannot access them so they need to have duplicate logic iniri-stringandiri-string-core, which is obviously bad for maintainability.Opting out semver by using
=x.y.zanytime foriri-string-corewill be an option, but it may be annoying to keep such a code clean.For example, exporting everything as
pubitem prevents compiler from checking unused items.The current situation doesn't look great for providing compile-time complex validation for dedicated types.