On Monday 21 February 2011 22:51:25 %u wrote: > Hm... so the entire issue here seems to be the capability to do > iteration and modification in a concurrent manner, right? > > IMHO that may not be worth the costs we're paying -- I would argue > that you normally shouldn't be modifying a collection that you're > iterating over in the first place; it just doesn't make any sense > when you're delaying everything. Sure, it would work fine if you > couldn't have more than one reference to any container (since every > range would would then have the same view of the container), but > when we're introducing delayed evaluation with ranges, I just don't > see how (or even why) it should be combinable with modification. > It's like trying to read from a database and concurrently modifying > the underlying storage by hand, bypassing the database... it just > doesn't work that way, outside of functional programming. So is it > really worth paying the price?
_Of course_, it's worth it. Do you never alter anything in a range? Functions like sort need to be able to alter the elements that the range refers to. Not to mention, there's generally no other way to alter elements in a container other than through a range to it unless you remove them and add new ones to replace them. The one exception would be if the container is random access, and then you can use the subscript operator to get at its elements. Ranges definitely need to be able to alter the elements that they contain. Sure, there are plenty of times when you don't need to do that, but there are times when you definitely do. And really, the problem here isn't really the concept of ranges - it's their implementation. The fact that you can't get the right type of range with the right elements in it is the problem. Doing something like building the take functionality into forward ranges would fix that problem. - Jonathan M Davis
