On Sun, Jan 5, 2014 at 10:18 PM, Ben Kloosterman <[email protected]> wrote:
> On Mon, Jan 6, 2014 at 5:24 AM, Jonathan S. Shapiro <[email protected]>wrote: > >> >> Exceptions don't need to be heap allocated and should not be. That's an >> implementation or a design bug, depending on your point of view. >> > > I wouldnt call it a bug . Unwinding can get messy with Exceptions on the > stack especially the usefull out of stack exception. > As William noted, OOM exceptions are statically preallocated. What stack do I push that exception onto? The reason that exceptions *must not* allocate in the heap is that this breaks any practical possibility of heap-free programming. To the extent possible, it is always better to capture mistakes at static >> compile time than at run time. A lot of the exceptions that C# FOREACH >> throws are things that can and should be type checked out. >> >> But I suspect we probably all agree about that. :-) >> > > Yes dependent types etc but collection modified while being enumerated is > not one of them... > Why on earth not? Surely if the collection type is frozen we need not consider any possibility of that exception happening! > ...interfaces being nice for business apps but you will want to take > such exceptions and checks out becuase you want to use it at a lower level. > That's exactly backwards. Lower level programming is far more critical than application programming. For exactly this reason, those checks *must not* be removed from the semantics. If the compiler can determine that they can't be reached, great. Otherwise they stay. What you called "unsafe foreach" is a reason to reject the contractor who ever uses it, and preferably to blacklist the programmer who inserted it. ie when we explcitly go " nothread noheap foreach " > I need to think about nothread - I'm suspicious that one simply isn't possible to check well enough to be of any value. It's a non-lexical property. But yes, in the presence of a noheap effect you are guaranteed that absolutely nothing the code does can allocate. This is one reason why it is so critical for core language expressions not to allocate. I'll go so far as to say that the *only* core operation that should allocate in the heap is "new". shap
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
