All of these have nothing to do with sealed ranges. They have to do with data lifetime. If you destroy data and then try to access it, you will have problems with or without sealed ranges. In addition, only one instance you show has a sealed range in it. The rest either don't have ranges or are not sealed.
Having a sealed range does not necessarily mean that the user cannot shoot themselves in the foot and delete the data while still maintaining references to it. This problem is mostly solved by having the data or at least the pointer to the data on the heap, destroyed by the GC when no longer needed. Even then, this does not rule out the user calling clear on the pointer. SealedRange is not a magic bullet for memory issues, and all these issues exist with or without sealed ranges or expensive copy construction. What SealedRange *does* do is allow the container to have complete control over the storage for the data. This means it can: a) intercept all accesses to the memory, including writes and reads. b) use abstracted allocation schemes. -Steve ----- Original Message ---- > From: SHOO <[email protected]> > Another viewpoint. > > Is SealedRange really appropriate? > > All these are caused by the same problem: > - http://ideone.com/x1Zus > - http://ideone.com/iM18Q > - http://ideone.com/TTin3 > - http://ideone.com/x4b0o > > We should consider that we grope the common solution for these problems. > It is the method that block the access to reference data of which > instance was deleted. > _______________________________________________ > phobos mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos > _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
