Passing array as const slows down code?

[Steven Schveighoffer]

On Fri, 27 Apr 2012 13:25:30 -0400, Joseph Rushton Wakeling  
<joseph.wakeling at webdrake.net> wrote:

> On 27/04/12 19:08, Steven Schveighoffer wrote:
>> weak purity, I think, is one of the most revolutionary ideas to come  
>> from D.
>> Essentially, we get compiler-checked pure functions that can be written
>> imperatively instead of functionally.
>
> I do agree with that; it's a very attractive aspect of D that a function  
> or object can be internally imperative but pure as far as the outside  
> world is concerned.  Seeing that documented in Andrei's writings was  
> another "Wow!" moment for me about D. :-)
>
> What concerned me here was that the way my reputation() function was set  
> up actually did change the public state of the object, which to my mind  
> isn't even weakly pure.  But I just wrote a fix which, contrary to my  
> fears, didn't affect the speed of the program.

Weakly pure simply means it can be called by a strong-pure function.  It  
has no other benefits except for that, and is basically a normal non-pure  
function otherwise.  It's a weird thing, and it's hard to wrap your mind  
around.  I don't think anyone has ever done it before, so it's hard to  
explain.

But the benefits are *enormous*.  Now, instead of pure versions of so many  
normal functions, much of the standard library can be marked as pure, and  
callable from either pure or unpure functions.  It opens up the whole  
library to pure functions which would otherwise be a painstaking porting  
effort.

>> If the function is weakly pure, then it cannot be optimized based on  
>> purity, so
>> I don't think there is any way marking it pure *hurts*.
>
> I was more concerned that the compiler wasn't identifying what to me was  
> a violation of purity.  I'm fairly sure I can also find a way to make  
> some of those "nothrow" functions throw an error ...

It depends on what your definition of "purity" is.  For D's definition,  
it's pure, otherwise the compiler would reject it.

The definition of pure for D is, it cannot accept any shared data as  
parameters, and it cannot access any global non-immutable data.  That's  
it.  There's no requirement for immutability of parameters or results.

In hindsight, D's 'pure' keyword really should be named something else,  
since it varies from the traditional definition of 'pure'.  But it is what  
it is now, and no changing it.

nothrow means it cannot throw an Exception.  It can still throw an error,  
or technically even something else derived from Throwable.  This is  
necessary, because otherwise, nothing could be nothrow (anything might  
throw an out of memory error).

-Steve