> > > 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! >
So everytime you have a shared mutable collection in a multi threaded environment on which your searching to determine elements to remove your going to create a new type and copy the elements by which time the original collection may have changed. > > >> ...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. > Im certainly NOT suggesting a generic unsafe foreach but a qualifier used in some cases , Right now this is very common ( of most languages) the runtime cheats and makes external C calls as do a number a of libs like i said look at string . User developed libs do likewise id much rather an unsafe keyword for 5 lines than linking in a bit of c code. Im not talking in 10 years when everything is done and implimented , but right now. Id much rather a few lines of code which the whole app depends on does not use bounds checking and stays in code rather than using C to achieve the same thing. Can we always eliminate bounds checking , eg on variable counts in multi threaded environments ? C# , Java and Mono can for critical cases because they cheat. > 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". > No issue on non allocating code only in compromising allocting code to handle it . So its a question of how we do this. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
