extendable hook for custom checks

[adamdruppe]

This is something I've been talking about for a while and now want to see about getting merged. Pretty minor change in here, the idea is just to provide an easy hook for projects to build upon. See the comment in rtinfo.d for the idea.

I'm not sure if this is mergeable right now, I couldn't quite tell how the .di files are generated or the html for that matter, we'd want to link this in to the website somehow too. But since the new module is empty it doesn't actually have to be compiled. It just needs to be found so the import just works when the user doesn't want to use the new hook.

On the newsgroup, a potential problem was brought up with getting this to work with rdmd. We might want to patch it too so we can easily override the core.* namespace there too. But I consider that a rdmd enhancement request/bug which is separate from this.

With this we can do static assert to do custom lint style checks on code or static this() to do custom runtime reflection without needing to modify the user modules. Just write your custom set in your rtinfo.d file and add it to your project's build dependencies.

[braddr]

How would these be composed? Consider multiple, not shipped together as a bundle, users of this feature. There needs to be an accompanying doc pull or more docs here in the source. Examples, when to use it, when not to, etc.

[adamdruppe]

Whoever writes the main function should also be in control of writing their own core.rtinfo file, since there can only be one of each in the program as a whole. The third party components might offer functions and instruct the user to call them or mix in their own templates in here, but they can't do it themselves.

I can add this to the doc comment or something too.

[braddr]

That kinda rules out using it for the reason it was introduced then, no?

[MartinNowak]

I'd rather let the compiler lookup the RTInfo from the instantiation scope.
The way it's implemented currently (always using RTInfo in object) is pretty useless.
To support heterogeneous RTInfo types we could introduce an RTInfo interface in object.

[andralex]

Ionno what to think about this, particularly with no examples and very little design. Thoughts?

[adamdruppe]

On Sat, Mar 15, 2014 at 09:35:55PM -0700, Andrei Alexandrescu wrote:

Ionno what to think about this, particularly with no examples and very little design. Thoughts?

I talked about it a little on the newsgroup a while ago too:

http://forum.dlang.org/thread/majnjuhxdefjuqjlpbmv@forum.dlang.org

[adamdruppe]

On Tue, Feb 25, 2014 at 08:54:08PM -0800, Brad Roberts wrote:

That kinda rules out using it for the reason it was introduced then, no?

Not really, a library developer can use one build configuration to get
their stuff and then the library user does another to get what they want.

module mylib.rtinfo;

mixin template ProjectRTInfo(T) {
/* whatever my lib needs */
}

mylib/build/core/config.d
module core.rtinfo;
mixin template ProjectRTInfo(T) {
import lib = mylib.rtinfo;
mixin lib.ProjectRTInfo!T;

/* Other potentially breaking stuff, like the library's
   own custom lint rule implementations */

}

The library compiles: dmd mylib.d mylib_rtinfo.d mylib/build/core/config.d

Now the user takes it:

userfile/core/config.d
module core.rtinfo;
mixin template ProjectRTInfo(T) {
import lib = mylib.rtinfo;
mixin lib.ProjectRTInfo!T; // note this did not bring the lib's internal lint

import lib2 = otherlib.rtinfo;
mixin lib2.ProjectRTInfo!T;

/* and some more custom checks for this particular thing */
// runOurLint!T;

}

It is a bit of effort to bring it together from multiple sources, but it isn't
that hard and could potentially be automated by a build tool if we all follow
the same pattern.

[adamdruppe]

On Thu, Feb 27, 2014 at 10:48:49AM -0800, Martin Nowak wrote:

The way it's implemented currently (always using RTInfo in object) is pretty useless.

I don't agree, it is hugely useful.... if you either are willing to edit
object.d or have some way to inject some code into it.

We need it to have some shared stuff because otherwise it would kill the
GC precision use-case: the GC needs the same data on every type in the
program and local instantiation wouldn't include that (at least not straightforwardly).

To support heterogeneous RTInfo types we could introduce an RTInfo interface in object.

Though, I do agree this is a good idea anyway. Right now, I'm looking at
using RTInfo more as a way to introduce static this() and static assert()
for each type rather than actually extending the rtinfo structure itself -
that's still the responsibility of object.d alone. But with an interface,
we could extend it more.

[andralex]

I talked about it a little on the newsgroup a while ago too:
http://forum.dlang.org/thread/majnjuhxdefjuqjlpbmv@forum.dlang.org

I remember - doesn't quite count as design :o). It's a nice idea, needs more love (fleshing out, docs, examples, etc).

[andralex]

ping?

[complexmath]

This has been open since February with very little activity. I think it's long past time for us to close this one.

[adamdruppe]

On Thu, Sep 25, 2014 at 01:33:30PM -0700, Sean Kelly wrote:

This has been open since February with very little activity. I think it's long past time for us to close this one.

yeah there's too much disagreement in what this would actually do.