ref returns and properties

[Sergey Gromov]

Mon, 26 Jan 2009 08:06:05 -0800, Andrei Alexandrescu wrote:

> Anyhow, here's a simple D example. Consider we define a BigInt type as a 
> value-type struct: when you copy a BigInt to another, the latter becomes 
> an independent copy:
> 
> BigInt a = 100;
> BigInt b = a;
> ++b;
> assert(a == 100);
> 
> BigInt's copy constructor would allocate memory dynamically, which means 
> it may throw and also that it is inefficient to copy BigInt objects 
> unwittingly.
> 
> So far, so good. Now say we define some range that iterates over 
> BigInts. If that range chooses to implement head() as a property, then a 
> copy is created whenever you ask for head. The small problem is that 
> that's inefficient. The larger problem is that there is no way to 
> correctly e.g. sort such a range. Sorting hinges on swap, and with 
> properties you can't ever swap without risking to throw. Sort would end 
> up throwing, and not only throwing, but losing state irretrievably while 
> at it. Well that's not a foundation we want to build D on, do we?

This will happen in C++, too, if operator*() decides to throw.
Algorithms are correct only if objects they manipulate obey the rules.
It seems like your rule is, 'forward ranges are nothrow.'  Any senior
ranges included.  Or maybe throwing next() or empty() are less
dangerous?