Shap any comment on this "Can we ensure that the interface value type which is wrapping a value type ( we don't care for reference) is always located in the same region /stack as the value type wrapped ? Then worst case region analysis may prevent the region closing at which point we can choose to box it with warning or report as an error ."
If we think such interfaces are always short lived ( which is likely true) then the above has a rare worst case of a region deallocation being held up by the interface. One more comment , objects are very often creates slightly prior to the interfaces ,( in our case on the stack) which are then passed as params which are then moved to the heap as they are members of heap objects. Will moving between heap and stack here result in worse performance ? Should interfaces wrapping heap objects always be allocated on the heap ? Also what about interfaces to internal value objects ? On Wed, Jan 8, 2014 at 2:56 PM, Jonathan S. Shapiro <[email protected]>wrote: > On Tue, Jan 7, 2014 at 7:28 PM, Ben Kloosterman <[email protected]>wrote: > >> 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. >> > > That's not what I said at all. I said that when we know the collection is > immutable we can derive that no CollectionChanged exception is possible, > and we can exploit that knowledge. > But it moves from the point of the statement...eg my point is its nice to have higher level concepts in foreach by using it for low level programming you create significant constraints . Sure you will have frozen collections ( you have readonly collections now) but that has less to do with the point . A lot of concurrent code will be doing mutations while others iterate and often iterate and then mutate ( eg to find the element to remove) so will this lead to 2 foreach statements ? Or different behaviour if wrapping non heap types . > > >> 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 >> > > What I said. If the compiler cannot *prove* that unsafe foreach is in > fact safe, then it isn't safe. Period. Calls to external code are > different. Their signature says what the contract is. If the implementation > fails to honour the contract, bad on ya. > Disagree if your forced to go external then the language has failed at something serious. Right now this happens in every language but the runtime gets special treatment that allows "unsafe" or non marshalled links in C . Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
