Disable GC entirely

[Manu]

On 8 April 2013 04:41, Rob T <alanb at 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130408/3517c64e/attachment.html>