another cool RTInfo trick - i want in runtime

[Jacob Carlborg]

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