xxxInPlace or xxxCopy?

[Don]

Steven Schveighoffer wrote:
> 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

If you don't use the return value of a strongly pure, nothrow function, 
you could be given a 'expression has no effect' error.
Currently the function call is silently dropped.