On 8 April 2013 04:41, Rob T <alanb@ucora.com> wrote:

Ideally, I think what we need is 1) a better GC since the pros with using one are very significant, and 2) the ability to selectively mark sections of code as "off limits" to all GC dependent code. What I mean by this is that the compiler will refuse to compile any code that makes use of automated memory allocations for a @noheap marked section of code.

I wonder if UDA's could be leveraged to implement this in a library?

UDA's can not permute the type, so I guess it's impossible to implement something like @noalloc that behaves like @nothrow in a library...

I wonder what it would take, it would be generally interesting to move some of the built-in attributes to UDA's if the system is rich enough to express it.

As a side though though, the information about whether a function can allocate could be known implicitly by the compiler if it chose to track that detail. I wonder if functions could gain a constant property so you can assert on that detail in your own code?

ie:

void myFunction()

{

// does stuff...

}

{

// ...code that i expect not to allocate...

static assert(!myFunction.canAllocate);

myFunction();

}

This way, I know for sure my code is good, and if I modify the body of myFunction at some later time (or one of its sub-calls is modified), for instance, to make an allocating library call, then i'll know about it the moment I make the change.

Then again, I wonder if a formal attribute @noalloc would be useful in the same way as @nothrow? The std library would be enriched with that information... issues like the one where toUpperInPlace() was allocating (which is clearly a bug, it's not 'in place' if it's allocating), should have ideally been caught at the time of authoring the function.

Eliminating common sources of programmer errors and thus reducing bug counts is always an interesting prospect... and it would offer a major tool towards this thread's topic :)