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.

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.

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

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

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

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

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.