xxxInPlace or xxxCopy?

[Steven Schveighoffer]

On Thu, 20 Jan 2011 10:36:00 -0500, foobar <foo at bar.com> wrote:

> Jonathan M Davis Wrote:
>
>> On Thursday 20 January 2011 03:51:48 Trass3r wrote:
>> > If such an annotation was introduced, it should be the other way  
>> around.
>> > But imo discarding a return value should always result in a warning,
>> > the function returns something for a reason.
>>
>> Actually, there are plenty of cases where you throw away the return  
>> value. A
>> number of overloaded operators are prime examples - such as opAssign.
>> std.algorithm.sort both sorts in place _and_ returns a sorted range (so  
>> that
>> other algorithms can then know that the range is sorted). It's really  
>> quite easy
>> to get legitimate cases where throwing away the return value makes  
>> perfect
>> sense. Now, if you're dealing with a strongly pure function which  
>> throws away
>> its return value, then yes, that's definitely bug, since the only  
>> effect of the
>> function is its return value. Frequently however, that's not the case.
>>
>> Yes, you can have bugs because you didn't actually use the return value  
>> of a
>> function, but it's that necessarily uncommon to have function calls  
>> which
>> legitimately throw away their return value.
>>
>> - Jonathan M Davis
>
> You brought up an interesting idea:
> D already supports purity and as you said it doesn't make sense to  
> discard return values of such functions.
> Therefore, it makes sense that for pure functions, this would result in  
> a compile time error.

Pure functions no longer have that requirement.  You can pass mutable  
references to pure functions, which makes them weak-pure.

-Steve