www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - another cool RTInfo trick - i want in runtime

reply "Adam D. Ruppe" <destructionator gmail.com> writes:
Check this out. Modify your druntime slightly. In object.di, find 
template RTInfo(T) and add this bit:

     import core.config;
     alias checkResult = TypeCheck!T;

Then, pop open import/core/config.d and put these contents in it:

module core.config;
template TypeCheck(T) {
     enum TypeCheck = true;
}


Compile a program, any program. Should be no difference in 
anything - no errors, no changes to the binary, no compile 
slowdown - from before the modifications.


Now, create a file named anything you want with these contents:

module core.config;
template TypeCheck(T) {
   static if(T.stringof == "Cool")
     static assert(0, "No type named 'Cool' is allowed!");
   enum TypeCheck = true;
}


Compile your program, should still work. Then add "struct Cool{}" 
to it anywhere... and you get a compile error.



Brothers and sisters, I've talked to you before about doing 
custom RTInfo using __traits(compiles) tricks to look for the 
config module, but my previous ways - while they worked - sucked 
because the compiler would look for the module over and over 
again, slowing things down a bit.

This new method achieves success on all counts. By offering a 
file with druntime to be the module up front, the compiler does 
no special searching, it finds it. It is a trivial file, so 
impact on compile speed is negligible.

But then, if you offer your own file with the same module name on 
the command line, dmd looks THERE first, finds your special code, 
and knows to skip searching the import path! Even true for 
object.d, since this is all in templates with local imports; the 
template still needs to be instantiated.

Since this object.d doesn't actually store anything* in the 
RTInfo itself, there's no worry of binary incompatibilities 
resulting from separate compiliation with different rtinfo 
modules. It simply provides a hook into the types for checking.

Using this, we can automatically check all kinds of per-project 
requirements. Don't want virtual functions in your class unless 
they are reviewed? Make your TypeCheck loop over them and look 
for a UDA, issuing a static assert if not there. Don't want 
references to un-owned mutable data? Ditto. Have a naming 
convention to check? Can do that too.


I see lots of upsides, and the downsides from my last experiment 
with this I believe have been eliminated. Am I missing something? 
I wanna do a druntime pull request!


* User data extensions could potentially be allowed if RTInfo 
stored a pointer to an interface, which may be null. Other 
modules may implement the interface differently, but as long as 
they implement it (or set it to null), it should still have 
consistent binary compatibility.

You might make object.d's RTInfo create a static struct with 
information the GC needs first, then a pointer to the user 
defined data. The RTInfo template ultimately resolves to the 
pointer to that struct. The data itself is consistent - still 
defined in only one place, druntime itself, and the GC info is 
available right there, no added indirection, and we have the hook 
for user additions too, all under a consistent interface.

You can also add runtime info about a type using static 
constructors:
===
module core.config;

string[] types;

template TypeCheck(T) {
     enum TypeCheck = true;

     shared static this() {
         types ~= T.mangleof;
     }
}
===
module test500.d
struct Cool {}

void main() {
	import core.config, std.stdio;
	writeln(types);
}
===
dmd test500.d rtinfo.d

$ ./test500
["S7test5004Cool", 
"S3std5array17__T8AppenderTAyaZ8Appender4Data", 
"S3std5array17__T8AppenderTAyaZ8Appender"]


Run time info available about all the types used in that program!


Soooo yeah, this is pretty much a pure win all around to my eyes. 
Am I blind to the suck?
Jan 16 2014
next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 16 January 2014 at 15:57:05 UTC, Adam D. Ruppe wrote:
 Now, create a file named anything you want with these contents:

I guess this won't work with rdmd, then?
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 16 January 2014 at 16:09:52 UTC, Vladimir Panteleev 
wrote:
 I guess this won't work with rdmd, then?

That's due to a deficiency in rdmd: tt doesn't let you forward all the available module options to dmd, even though it would make sense to do it, for this kind of replaceable config module thing and also for replacing say one phobos file at a time for doing dev work on that . rdmd should be fixed to allow you to pass more than one explicit module (maybe just add an option like --additional-dmd-option=file.d).
Jan 16 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 16 January 2014 at 16:21:25 UTC, Adam D. Ruppe wrote:
 On Thursday, 16 January 2014 at 16:09:52 UTC, Vladimir 
 Panteleev wrote:
 I guess this won't work with rdmd, then?

That's due to a deficiency in rdmd: tt doesn't let you forward all the available module options to dmd, even though it would make sense to do it, for this kind of replaceable config module thing and also for replacing say one phobos file at a time for doing dev work on that . rdmd should be fixed to allow you to pass more than one explicit module (maybe just add an option like --additional-dmd-option=file.d).

That sounds overcomplicated. Why not move the standard search paths to after the users' ones? So that users can override Phobos and Druntime modules simply by creating them within their search path.
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 16 January 2014 at 16:26:49 UTC, Vladimir Panteleev 
wrote:
 Why not move the standard search paths to after the users' ones?

That might work too. Either way though, the compiler and language let you list additional modules and it all just works if you do, so rdmd should too... however it does. I don't use rdmd myself so the specific solution should probably be guided by people who do.
Jan 16 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 16 January 2014 at 16:37:16 UTC, Adam D. Ruppe wrote:
 I don't use rdmd myself so the specific solution should 
 probably be guided by people who do.

Well, the beauty of rdmd is that you don't need to mess with options in the general case. My setup is that generally I press "Enter" on a .d file and it is built into an .exe (if there is an entry point in any imported modules) - no other action required. If I had to modify the command line for every invocation, that would not work for my case, so I'd have to write a rdmd wrapper to look for additional command-line options in a configuration file in the current directory, or implement something like that in rdmd itself. If these requirements can be specified in the source code itself, that would be much better. In our case it would simply be the presence of a file in the project search path. An existing example of this is pragma(lib) - instead of telling the user to specify which libraries to add to the linker command line, or providing a makefile (with all its problems), a pragma(lib) can be used to pull in those libraries automatically.
Jan 16 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 16 January 2014 at 16:26:49 UTC, Vladimir Panteleev 
wrote:
 Why not move the standard search paths to after the users' 
 ones? So that users can override Phobos and Druntime modules 
 simply by creating them within their search path.

Never mind, this is already the case! It depends on how you write your own sc.ini (I had mine with Phobos/Druntime in front).
Jan 16 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Thursday, 16 January 2014 at 17:10:42 UTC, Vladimir Panteleev 
wrote:
 On Thursday, 16 January 2014 at 16:26:49 UTC, Vladimir 
 Panteleev wrote:
 Why not move the standard search paths to after the users' 
 ones? So that users can override Phobos and Druntime modules 
 simply by creating them within their search path.

Never mind, this is already the case! It depends on how you write your own sc.ini (I had mine with Phobos/Druntime in front).

Probably we should pick one way or another as standard for packaging so that projects can rely on it.
Jan 16 2014
prev sibling next sibling parent "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 16 January 2014 at 15:57:05 UTC, Adam D. Ruppe wrote:
 Check this out. Modify your druntime slightly. In object.di, 
 find template RTInfo(T) and add this bit:

Suggestions: 1. I guess TypeCheck is a temporary name? I would suggest e.g. CustomRTInfo. 2. How about using a template mixin instead of a template? Then you can drop the dummy bool. I know that if you use a mixin, you can't refer to stuff that's in the scope where it's declared, but I think that's OK - because you probably don't want an object file for config.d anyway, since: 3. rdmd will not add config.d to the compiler's command line, since it lies in an excluded package "core" (so it's assumed it'll be in phobos.lib). But that's OK, since there will be no symbols in config.d to link against anyway! It all fits together quite nicely. You can access stuff in your main program by importing its modules within the template mixin.
Jan 16 2014
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 16 January 2014 at 15:57:05 UTC, Adam D. Ruppe wrote:
 Check this out. Modify your druntime slightly. In object.di, 
 find template RTInfo(T) and add this bit:

     import core.config;
     alias checkResult = TypeCheck!T;

 Then, pop open import/core/config.d and put these contents in 
 it:

 module core.config;
 template TypeCheck(T) {
     enum TypeCheck = true;
 }


 Compile a program, any program. Should be no difference in 
 anything - no errors, no changes to the binary, no compile 
 slowdown - from before the modifications.


 Now, create a file named anything you want with these contents:

 module core.config;
 template TypeCheck(T) {
   static if(T.stringof == "Cool")
     static assert(0, "No type named 'Cool' is allowed!");
   enum TypeCheck = true;
 }


 Compile your program, should still work. Then add "struct 
 Cool{}" to it anywhere... and you get a compile error.



 Brothers and sisters, I've talked to you before about doing 
 custom RTInfo using __traits(compiles) tricks to look for the 
 config module, but my previous ways - while they worked - 
 sucked because the compiler would look for the module over and 
 over again, slowing things down a bit.

 This new method achieves success on all counts. By offering a 
 file with druntime to be the module up front, the compiler does 
 no special searching, it finds it. It is a trivial file, so 
 impact on compile speed is negligible.

 But then, if you offer your own file with the same module name 
 on the command line, dmd looks THERE first, finds your special 
 code, and knows to skip searching the import path! Even true 
 for object.d, since this is all in templates with local 
 imports; the template still needs to be instantiated.

 Since this object.d doesn't actually store anything* in the 
 RTInfo itself, there's no worry of binary incompatibilities 
 resulting from separate compiliation with different rtinfo 
 modules. It simply provides a hook into the types for checking.

 Using this, we can automatically check all kinds of per-project 
 requirements. Don't want virtual functions in your class unless 
 they are reviewed? Make your TypeCheck loop over them and look 
 for a UDA, issuing a static assert if not there. Don't want 
 references to un-owned mutable data? Ditto. Have a naming 
 convention to check? Can do that too.


 I see lots of upsides, and the downsides from my last 
 experiment with this I believe have been eliminated. Am I 
 missing something? I wanna do a druntime pull request!


 * User data extensions could potentially be allowed if RTInfo 
 stored a pointer to an interface, which may be null. Other 
 modules may implement the interface differently, but as long as 
 they implement it (or set it to null), it should still have 
 consistent binary compatibility.

 You might make object.d's RTInfo create a static struct with 
 information the GC needs first, then a pointer to the user 
 defined data. The RTInfo template ultimately resolves to the 
 pointer to that struct. The data itself is consistent - still 
 defined in only one place, druntime itself, and the GC info is 
 available right there, no added indirection, and we have the 
 hook for user additions too, all under a consistent interface.

 You can also add runtime info about a type using static 
 constructors:
 ===
 module core.config;

 string[] types;

 template TypeCheck(T) {
     enum TypeCheck = true;

     shared static this() {
         types ~= T.mangleof;
     }
 }
 ===
 module test500.d
 struct Cool {}

 void main() {
 	import core.config, std.stdio;
 	writeln(types);
 }
 ===
 dmd test500.d rtinfo.d

 $ ./test500
 ["S7test5004Cool", 
 "S3std5array17__T8AppenderTAyaZ8Appender4Data", 
 "S3std5array17__T8AppenderTAyaZ8Appender"]


 Run time info available about all the types used in that 
 program!


 Soooo yeah, this is pretty much a pure win all around to my 
 eyes. Am I blind to the suck?

I guess that could work pretty well for a C++ friend emulation with UDA's! Were not you the one who wanted to show me an example for that with using RTInfo? Offer your way the possibility to check automatically for null references? With an UDA e.g. safe_ref or not_null
Jan 16 2014
parent Michel Fortin <michel.fortin michelf.ca> writes:
On 2014-01-17 00:03:19 +0000, "Meta" <jared771 gmail.com> said:

 On Thursday, 16 January 2014 at 23:56:14 UTC, Adam D. Ruppe wrote:
 // use it! notice that it is notnull already
 auto na = create!A();

That's neat. Didn't Andrei mention something about wanting new to be removed from the language and replaced with a library solution using allocators? If that were the case, it'd be pretty easy to enforce that class allocators return NotNull!T. It'd get rid of nullable references without needing a breaking language change.

In one C++ project of mine I have a make_new< T >(args...) template function that does exactly that. Pretty neat. The biggest downside to such an approach is that you're creating your own meta-language on top of the regular language (replacing the language syntax with your own). But it cannot really be avoided if you want NotNull to be usable. The next language facility you might have to duplicate is the cast (to keep the not-null "qualifier" when casting). Then maybe you'll want it to play nice with other the other "qualifier" type template Rebindable. -- Michel Fortin michel.fortin michelf.ca http://michelf.ca
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 16 January 2014 at 18:15:39 UTC, Vladimir Panteleev 
wrote:
 1. I guess TypeCheck is a temporary name? I would suggest e.g. 
 CustomRTInfo.

My first thought when writing this was the TypeCheck would just contain a bunch of static asserts to ensure the type matches whatever your project's special requirements are; it would act kinda like a plugin to the compiler's semantic check. (Actually, it does the bool because my first try was to use it as a template constraint, but if that fails, ti just stops the RTInfo from instantiating; it doesn't actually fail the compile like static assert inside does.) But CustomRTInfo is a good name too, especially if we are adding data.
 2. How about using a template mixin instead of a template?

If we actually mix it in that could change the binary layout of the thing though. We don't need the dummy bool btw, I just tried and it works the same without it.
 It all fits together quite nicely. You can access stuff in your 
 main program by importing its modules within the template mixin.

yes
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 16 January 2014 at 18:44:54 UTC, Namespace wrote:
 I guess that could work pretty well for a C++ friend emulation 
 with UDA's! Were not you the one who wanted to show me an 
 example for that with using RTInfo?

I've played with rtinfo a lot before, but I don't remember doing C++ friend emulation...
 Offer your way the possibility to check automatically for null 
 references? With an UDA e.g.  safe_ref or  not_null

I think those would be better done with the type info, like NotNull!t. What's cool about the RTInfo thing though is it is checked on everything, so it can check for the *absence* of a UDA as well as for the presence. You might say something must not have any nullable references unless specially marked. The rtinfo checker can confirm that: loop over all members, if it is potentially nullable and isn't marked with either NotNull or i_know_this_is_nullable_and_that_is_ok, it can throw an error. It is possible to do that kind of thing with static assert on the module level too.... sort of. See, the module level one for one can be forgotten and it can't access nested things in functions: void foo() { struct InnerStruct {} } // can't see foo.InnerStuct here! static assert(ModulePassesCheck!(mixin("this_module"))); But RTInfo *does* see InnerStruct, and you don't have to remember to add the check to your module too.
Jan 16 2014
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Thursday, 16 January 2014 at 19:13:42 UTC, Adam D. Ruppe wrote:
 On Thursday, 16 January 2014 at 18:44:54 UTC, Namespace wrote:
 I guess that could work pretty well for a C++ friend emulation 
 with UDA's! Were not you the one who wanted to show me an 
 example for that with using RTInfo?

I've played with rtinfo a lot before, but I don't remember doing C++ friend emulation...
 Offer your way the possibility to check automatically for null 
 references? With an UDA e.g.  safe_ref or  not_null

I think those would be better done with the type info, like NotNull!t. What's cool about the RTInfo thing though is it is checked on everything, so it can check for the *absence* of a UDA as well as for the presence. You might say something must not have any nullable references unless specially marked. The rtinfo checker can confirm that: loop over all members, if it is potentially nullable and isn't marked with either NotNull or i_know_this_is_nullable_and_that_is_ok, it can throw an error. It is possible to do that kind of thing with static assert on the module level too.... sort of. See, the module level one for one can be forgotten and it can't access nested things in functions: void foo() { struct InnerStruct {} } // can't see foo.InnerStuct here! static assert(ModulePassesCheck!(mixin("this_module"))); But RTInfo *does* see InnerStruct, and you don't have to remember to add the check to your module too.

All right, it wasn't you, it was Andrej Mitrovic on my thread http://forum.dlang.org/thread/pdshwedjqgquoibxhrxa forum.dlang.org#post-mailman.1977.1381065059.1719.digitalmars-d-learn:40puremagic.com The problem on a library NotNull struct is: nobody will use it, because it requires NotNull on both sides, by the caller and by the callee: ---- class A { } void safe_foo(NotNull!A na) { } void main() { NotNull!A na = NotNull!A(new A()); safe_foo(na); } ---- Which is a lot more effor than: ---- class A { } void safe_foo( safe_ref A na) { } void main() { A a = new A(); safe_foo(a); } ---- because it moves the check to the callee.
Jan 16 2014
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 All right, it wasn't you, it was Andrej Mitrovic on my thread 
 http://forum.dlang.org/thread/pdshwedjqgquoibxhrxa forum.dlang.org#post-mailman.1977.1381065059.1719.digitalmars-d-learn:40puremagic.com

 The problem on a library NotNull struct is: nobody will use it, 
 because it requires NotNull on both sides, by the caller and by 
 the callee:

 ----
 class A { }

 void safe_foo(NotNull!A na) { }

 void main() {
     NotNull!A na = NotNull!A(new A());
     safe_foo(na);
 }
 ----

 Which is a lot more effor than:

 ----
 class A { }

 void safe_foo( safe_ref A na) { }

 void main() {
     A a = new A();
     safe_foo(a);
 }
 ----

 because it moves the check to the callee.

Also it is far more readable and easier to write as a contract like: ---- void safe _foo(A a) in { assert(a !is null); } body { } ----
Jan 16 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2014-01-16 16:57, Adam D. Ruppe wrote:

 Brothers and sisters, I've talked to you before about doing custom
 RTInfo using __traits(compiles) tricks to look for the config module,
 but my previous ways - while they worked - sucked because the compiler
 would look for the module over and over again, slowing things down a bit.

 This new method achieves success on all counts. By offering a file with
 druntime to be the module up front, the compiler does no special
 searching, it finds it. It is a trivial file, so impact on compile speed
 is negligible.

 But then, if you offer your own file with the same module name on the
 command line, dmd looks THERE first, finds your special code, and knows
 to skip searching the import path! Even true for object.d, since this is
 all in templates with local imports; the template still needs to be
 instantiated.

Does this only work once? Say I have two libraries that use this technique, would that work? This seems somewhat complicated, depending on the orders of modules passed to the compiler.
 Since this object.d doesn't actually store anything* in the RTInfo
 itself, there's no worry of binary incompatibilities resulting from
 separate compiliation with different rtinfo modules. It simply provides
 a hook into the types for checking.

No, not yet. As far as I know, the idea was to use RTInfo to collect and store type info for a precise GC.
 Using this, we can automatically check all kinds of per-project
 requirements. Don't want virtual functions in your class unless they are
 reviewed? Make your TypeCheck loop over them and look for a UDA, issuing
 a static assert if not there. Don't want references to un-owned mutable
 data? Ditto. Have a naming convention to check? Can do that too.


 I see lots of upsides, and the downsides from my last experiment with
 this I believe have been eliminated. Am I missing something? I wanna do
 a druntime pull request!

I have had a different idea for a solution to this problem for a while. That is, add a new manifest constant to object.d, called rtInfo. This will act like a UDA. Any template with the object.rtInfo UDA attached to itself will behave just as RTInfo does today. module object; enum rtInfo; rtInfo template RTInfo (T) { enum RTInfo = null; } module foo.check_virtual_methods; rtInfo template CheckVirtualMethods (T) { static if (!containsVirtualMethods!(T)) static assert(false, "Error, contains virtual methods"); enum CheckVirtualMethods = null; } An idea for storing data in TypeInfo is to create an associative array. The keys would be the fully qualified name of the template, in this case "foo.check_virtual_methods.CheckVirtualMethods". The values would be whatever the template evaluates to. There's one problem with this, the associative array would need to be built at runtime due to separate compilation. -- /Jacob Carlborg
Jan 16 2014
parent Jacob Carlborg <doob me.com> writes:
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
Jan 17 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Thu, 16 Jan 2014 15:57:04 +0000
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 Check this out. Modify your druntime slightly. In object.di, find 
 template RTInfo(T) and add this bit:
 
      import core.config;
      alias checkResult = TypeCheck!T;
 
 Then, pop open import/core/config.d and put these contents in it:
 
 module core.config;
 template TypeCheck(T) {
      enum TypeCheck = true;
 }
 
 
 Compile a program, any program. Should be no difference in 
 anything - no errors, no changes to the binary, no compile 
 slowdown - from before the modifications.
 
 
 Now, create a file named anything you want with these contents:
 
 module core.config;
 template TypeCheck(T) {
    static if(T.stringof == "Cool")
      static assert(0, "No type named 'Cool' is allowed!");
    enum TypeCheck = true;
 }
 
 
 Compile your program, should still work. Then add "struct Cool{}" 
 to it anywhere... and you get a compile error.
 
 
 
 Brothers and sisters, I've talked to you before about doing 
 custom RTInfo using __traits(compiles) tricks to look for the 
 config module, but my previous ways - while they worked - sucked 
 because the compiler would look for the module over and over 
 again, slowing things down a bit.
 
 This new method achieves success on all counts. By offering a 
 file with druntime to be the module up front, the compiler does 
 no special searching, it finds it. It is a trivial file, so 
 impact on compile speed is negligible.
 
 But then, if you offer your own file with the same module name on 
 the command line, dmd looks THERE first, finds your special code, 
 and knows to skip searching the import path! Even true for 
 object.d, since this is all in templates with local imports; the 
 template still needs to be instantiated.
 
 Since this object.d doesn't actually store anything* in the 
 RTInfo itself, there's no worry of binary incompatibilities 
 resulting from separate compiliation with different rtinfo 
 modules. It simply provides a hook into the types for checking.
 
 Using this, we can automatically check all kinds of per-project 
 requirements. Don't want virtual functions in your class unless 
 they are reviewed? Make your TypeCheck loop over them and look 
 for a UDA, issuing a static assert if not there. Don't want 
 references to un-owned mutable data? Ditto. Have a naming 
 convention to check? Can do that too.
 
 
 I see lots of upsides, and the downsides from my last experiment 
 with this I believe have been eliminated. Am I missing something? 
 I wanna do a druntime pull request!
 
 
 * User data extensions could potentially be allowed if RTInfo 
 stored a pointer to an interface, which may be null. Other 
 modules may implement the interface differently, but as long as 
 they implement it (or set it to null), it should still have 
 consistent binary compatibility.
 
 You might make object.d's RTInfo create a static struct with 
 information the GC needs first, then a pointer to the user 
 defined data. The RTInfo template ultimately resolves to the 
 pointer to that struct. The data itself is consistent - still 
 defined in only one place, druntime itself, and the GC info is 
 available right there, no added indirection, and we have the hook 
 for user additions too, all under a consistent interface.
 
 You can also add runtime info about a type using static 
 constructors:
 ===
 module core.config;
 
 string[] types;
 
 template TypeCheck(T) {
      enum TypeCheck = true;
 
      shared static this() {
          types ~= T.mangleof;
      }
 }
 ===
 module test500.d
 struct Cool {}
 
 void main() {
 	import core.config, std.stdio;
 	writeln(types);
 }
 ===
 dmd test500.d rtinfo.d
 
 $ ./test500
 ["S7test5004Cool", 
 "S3std5array17__T8AppenderTAyaZ8Appender4Data", 
 "S3std5array17__T8AppenderTAyaZ8Appender"]
 
 
 Run time info available about all the types used in that program!
 
 
 Soooo yeah, this is pretty much a pure win all around to my eyes. 
 Am I blind to the suck?

This solve quite a few issues at once! It looks like stuff that could only be done with compiler extensions or AST manipulations and yet it works with a simple template. Just for the neat "once in a lifetime" idea it should be accepted. :) -- Marco
Jan 16 2014
prev sibling next sibling parent "Tove" <tove fransson.se> writes:
On Thursday, 16 January 2014 at 15:57:05 UTC, Adam D. Ruppe wrote:
 Soooo yeah, this is pretty much a pure win all around to my 
 eyes. Am I blind to the suck?

Wow, great trick! I'd love to see this merged.
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
This is a bit of a side discussion because the RTInfo can't 
*change* the type, it can only look at it. It is more like a 
centralized place to static asserts or maybe static data than an 
AST macro.

But...

On Thursday, 16 January 2014 at 19:32:10 UTC, Namespace wrote:
 The problem on a library NotNull struct is: nobody will use it, 
 because it requires NotNull on both sides, by the caller and by 
 the callee:

That's a lot of the benefit: the type system forces you to handle it sooner rather than later, so you can see where the invalid state came from.
     NotNull!A na = NotNull!A(new A());

This could be easily automated though with a helper function: NotNull!T create(T, Args...)(Args args) { return assumeNotNull(new T(args)); } // use it! notice that it is notnull already auto na = create!A(); And then you can just use it.
 Also it is far more readable and easier to write as a contract

That's what I tend to do now but the advantage of NotNull!() is catching it earlier.
Jan 16 2014
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 16 January 2014 at 23:56:14 UTC, Adam D. Ruppe wrote:
 // use it! notice that it is notnull already
 auto na = create!A();

That's neat. Didn't Andrei mention something about wanting new to be removed from the language and replaced with a library solution using allocators? If that were the case, it'd be pretty easy to enforce that class allocators return NotNull!T. It'd get rid of nullable references without needing a breaking language change.
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 16 January 2014 at 20:13:29 UTC, Jacob Carlborg 
wrote:
 Does this only work once? Say I have two libraries that use 
 this technique, would that work?

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 } hmmm Vladimir might be right that the custom info thing would be better done as a mixin template, then we could throw all this right in there and maybe build the whole class. I've gotta try it, I'm not sure yet.
 No, not yet. As far as I know, the idea was to use RTInfo to 
 collect and store type info for a precise GC.

Yeah, RTInfo is one of the most potentially cool things that has sat untapped for a long time.
 I have had a different idea for a solution to this problem for 
 a while. That is, add a new manifest constant to object.d, 
 called rtInfo. This will act like a UDA. Any template with the 
 object.rtInfo UDA attached to itself will behave just as RTInfo 
 does today.

I think that would need compiler support though 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.
 An idea for storing data in TypeInfo is to create an 
 associative array. The keys would be the fully qualified name 
 of the template, in this case 
 "foo.check_virtual_methods.CheckVirtualMethods". The values 
 would be whatever the template evaluates to. There's one 
 problem with this, the associative array would need to be built 
 at runtime due to separate compilation.

Yeah, I've played with this idea before too, it is definitely doable today.
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Thursday, 16 January 2014 at 20:16:59 UTC, Marco Leise wrote:
 It looks like
 stuff that could only be done with compiler extensions or AST
 manipulations and yet it works with a simple template.

Yeah, though remember that it can't actually manipulate the type, it just looks and can build up other data or issue errors, but not change the code it is looking at.
Jan 16 2014
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 17 January 2014 at 00:03:21 UTC, Meta wrote:
 Didn't Andrei mention something about wanting new to be removed 
 from the language and replaced with a library solution using 
 allocators?

I'm not sure if he's on board, but that's something I've been wanting for a while. Probably won't happen though, the new operator has a lot of fans (I kinda like it myself and fear the massive amount of code breakage removing it would cause). But we could still use specialized alternatives - new being there doesn't prohibit using a create function.
Jan 16 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 17 Jan 2014 00:15:51 +0000
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 On Thursday, 16 January 2014 at 20:16:59 UTC, Marco Leise wrote:
 It looks like
 stuff that could only be done with compiler extensions or AST
 manipulations and yet it works with a simple template.

Yeah, though remember that it can't actually manipulate the type, it just looks and can build up other data or issue errors, but not change the code it is looking at.

Right. It did get me interested in how UDAs work though, since I never really looked at them when they were introduced. The compiler can cope with a lot of template magic I throw at it now. I'm sure I would have had a dozen errors already with 2.063. I'm investigating "data driven" library bindings. E.g. some template contains function pointers with UDAs that describe how wrappers are to be generated that turn getError() calls into D exceptions and turn D strings into C char* and similar tricks, like handling API changes from one version to the next. -- Marco
Jan 16 2014
prev sibling next sibling parent Marco Leise <Marco.Leise gmx.de> writes:
Am Fri, 17 Jan 2014 00:17:58 +0000
schrieb "Adam D. Ruppe" <destructionator gmail.com>:

 On Friday, 17 January 2014 at 00:03:21 UTC, Meta wrote:
 Didn't Andrei mention something about wanting new to be removed 
 from the language and replaced with a library solution using 
 allocators?

I'm not sure if he's on board, but that's something I've been wanting for a while. Probably won't happen though, the new operator has a lot of fans (I kinda like it myself and fear the massive amount of code breakage removing it would cause). But we could still use specialized alternatives - new being there doesn't prohibit using a create function.

The state of NotNull without it being a language feature would still be a bit silly. A good implementation allows promotion to NotNull like this: void foo(Object o) { if (o !is null) { bar(o); } } void bar(NotNull!Object) {} Maybe it could be implemented like "if (__ctfe)". -- Marco
Jan 16 2014
prev sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 17 January 2014 at 07:35:00 UTC, Marco Leise wrote:
 void foo(Object o) {
     if (o !is null) {
         bar(o);
     }
 }

My current NotNull draft allows this: http://arsdnet.net/dcode/notnull.d int b; int* bp = &b; if(auto a = bp.checkNull) { static assert(is(typeof(a == NotNull!(int*)))); } else { assert(0); } So the type of bp doesn't change like it might when built into the language but since we can do if(auto a = ...) it is pretty close. Thanks to Andrej Mitrovic for the checkNull code.
Jan 17 2014