> The "pragmatic workaround" would probably be "Don't export the fields, > then.", which works until there is a fourth module which actually needs > access to them...
This will simply not happen because types being abstract remain abstract, they can't be opened with the underlying type or fields outside the defining module. * Rule of thumb: Half pregnancy is never a good idea conceptually. > As to #2: imagine #1 was solved, if there was a macro makeApi(Tcon) which > generates exported delegate procs for the ones defined in mdlImpl (instead of > the re-exports in my code), would that meet your criteria? Macros would not help here, they have a peep hole look on the AST only . If they are intended work, the would need access to the entire environment. This is the main point with concepts: Concepts are _orthogonal_ to the visibility aka "module" system in Nim , they have to overcome the limitations of these visibility rules. So, a concept should be able to find out that a specified `proc func` can be found somewhere in the module tree and the implementer/user _should not be enforced to do that for the compiler_ . Then, but only then, concepts would become convenient to use. There are cheaper solutions possible though: Here : <https://forum.nim-lang.org/t/8219> (export markers for procs) and here <https://forum.nim-lang.org/t/7925> (compiler building its own concept for a module, detecting "prototype" behaviour).
