<div dir="ltr">On 8 April 2013 04:41, Rob T <span dir="ltr"><<a href="mailto:alanb@ucora.com" target="_blank">alanb@ucora.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">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.</span></div>
</blockquote><div><br></div><div style>I wonder if UDA's could be leveraged to implement this in a library?</div><div style>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...</div>
<div style>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.</div><div style><br></div><div style>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?</div>
<div style>ie:</div><div style><br></div><div style>void myFunction()</div><div style>{</div><div style>  // does stuff...</div><div style>}</div><div style><br></div><div style><br></div><div style>{</div><div style>  // ...code that i expect not to allocate...</div>
<div style><br></div><div style>  static assert(!myFunction.canAllocate);<br></div><div style><br></div><div style>  myFunction();</div><div style>}</div><div style><br></div><div style>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.</div>
<div style><br></div><div style>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.</div>
<div style>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 :)</div></div></div></div>