On 2014-01-17 01:04, Adam D. Ruppe wrote:
No, then you'd get complaints about the module being defined in two files. This would be a once-per-project thing.Libraries however could provide helper functions with instructions for the user to call them in their project file. For example module my.serialization; mixin template SerializationAdditionToTypeInfo(T) { Whatever serialize() { ..... } } and then the user would open up their magic file module core.config; // BTW this name is just because it was on my mind from another discussion with it for enabled features template CustomRtInfo(T) { import my.serialization; mixin SerializationAdditionToTypeInfo!T; // you can also do other library's stuff here }
Ok, I see.
Yeah, RTInfo is one of the most potentially cool things that has sat untapped for a long time.
You don't want to remove this possibility. Storing the data in type info is a must, for this use case.
I think that would need compiler support though
Yes, compiler support is necessary. But adding something like a standard core.config module would be similar.
and might not work as well when compiling two files separately since then part of the rtinfo wouldn't get checked. True, here you'd have to include the config file each time you compile a file, but at least that bit is centralized so easier to manage.
I was thinking that for most cases, even when doing separate complication, the files would be included via the -I flag as "header" files. With my suggestion you don't need to modify your own CustomRtInfo template. Just make sure the file containing @rtInfo is processed one way or an other by the compiler. It also doesn't depend on the order of the modules. We already have some linker problems with because of this. It don't think it's a good idea to add "a new feature" that depends on this.
-- /Jacob Carlborg
