import std.stdio;

int pow2(int val) pure
{
    if (__ctfe)
        return 6;
    else
        return val * val;
}

void main()
{
           assert(pow2(3) == 9);
    static assert(pow2(3) == 6);

    writeln("9 = 6 ... I knew it! '6' was faking it all along");
    readln();
}

On 01-10-2012 07:40, Tommi wrote:
> import std.stdio;
>
> int pow2(int val) pure
> {
>      if (__ctfe)
>          return 6;
>      else
>          return val * val;
> }
>
> void main()
> {
>             assert(pow2(3) == 9);
>      static assert(pow2(3) == 6);
>
>      writeln("9 = 6 ... I knew it! '6' was faking it all along");
>      readln();
> }

This is a corner case.

__ctfe is there to allow special-cased CTFE code when absolutely necessary. By necessity, this separates a function into two worlds: compile time and run time.

As far as purity goes, pow2 *is* pure. It just does something different depending on whether you run it at compile time or run time. I don't see this as a problem in practice.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen wrote:
>
> As far as purity goes, pow2 *is* pure. ...

According to http://en.wikipedia.org/wiki/Pure_function it's not:

"The [pure] function always evaluates the same result value given the same argument value(s)"

On Monday, October 01, 2012 07:43:59 Alex Rønne Petersen wrote:
> This is a corner case.
> 
> __ctfe is there to allow special-cased CTFE code when absolutely necessary. By necessity, this separates a function into two worlds: compile time and run time.
> 
> As far as purity goes, pow2 *is* pure. It just does something different depending on whether you run it at compile time or run time. I don't see this as a problem in practice.

It would be kind of like complaining that a pure function returns different values on Linux and Windows due to a version statement or static if. It's just that in the thing that varies is compile time vs runtime not the target machine. e.g.

int func(int val) pure
{
    version(linux)
        return val + 2;
    else version(Windows)
        return val + 3;
}

- Jonathan M Davis

On Monday, October 01, 2012 07:58:39 Tommi wrote:
> On Monday, 1 October 2012 at 05:43:39 UTC, Alex Rønne Petersen
> 
> wrote:
> > As far as purity goes, pow2 *is* pure. ...
> 
> According to http://en.wikipedia.org/wiki/Pure_function it's not:
> 
> "The [pure] function always evaluates the same result value given
> the same argument value(s)"

Forget what Wikipedia says about pure. If you focus on that, you're going to be complaining about D's pure left and right, because what it's talking about and what D does are related but very different. D takes a very practical approach to functional purity. You should read this:

http://stackoverflow.com/questions/8572399

- Jonathan M Davis

On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
>
> It would be kind of like complaining that a pure function returns different
> values on Linux and Windows due to a version statement or static if. It's just
> that in the thing that varies is compile time vs runtime not the target
> machine. e.g.


Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that:

void main()
{
    auto x = pow2(3);
    enum y = pow2(3);

    assert(x == y + 3);

    writeln("Take that mr. \"math\" professor!");
    readln();
}

On 9/30/2012 11:09 PM, Tommi wrote:
> On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
>>
>> It would be kind of like complaining that a pure function returns different values on Linux and Windows due to a version statement or static if. It's just that in the thing that varies is compile time vs runtime not the target machine. e.g.
> 
> 
> Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that:
> 
> void main()
> {
>     auto x = pow2(3);
>     enum y = pow2(3);
> 
>     assert(x == y + 3);
> 
>     writeln("Take that mr. \"math\" professor!");
>     readln();
> }

So, Tommi, do you have a suggestion or proposal to make or are you just trying to point and snicker?  There's a multitude of ways that bad programmers can write bad code.

On Monday, October 01, 2012 08:09:38 Tommi wrote:
> On Monday, 1 October 2012 at 06:01:24 UTC, Jonathan M Davis wrote:
> > It would be kind of like complaining that a pure function
> > returns different
> > values on Linux and Windows due to a version statement or
> > static if. It's just
> > that in the thing that varies is compile time vs runtime not
> > the target
> > machine. e.g.
> 
> Actually... let's not even worry about the definition of the word 'pure'. Let's just ask ourselves: do we really want to live in a world where people can write code like that:
> 
> void main()
> {
>      auto x = pow2(3);
>      enum y = pow2(3);
> 
>      assert(x == y + 3);
> 
>      writeln("Take that mr. \"math\" professor!");
>      readln();
> }

Then don't write a function which claims to square a value and does something else. That's just bad naming. No language is going to prevent programmers from being idiots.

A function which uses __ctfe should probably do essentially the same thing at both runtime and compile time, but it _has_ __ctfe, because the runtime implementation won't work at compile time, and it's up to the programmer to make sure that the function does what it's supposed to at both compile time and runtime. The compiler can't possibly enforce that.

- Jonathan M Davis

On Monday, 1 October 2012 at 06:13:51 UTC, Brad Roberts wrote:
>
> So, Tommi, do you have a suggestion or proposal to make or are you just trying to point and snicker?  There's a
> multitude of ways that bad programmers can write bad code.

I can't provide a solution until we've agreed that there is a problem.

On Monday, 1 October 2012 at 06:18:48 UTC, Jonathan M Davis wrote:
>
> A function which uses __ctfe should probably do essentially the same thing at
> both runtime and compile time, but it _has_ __ctfe, because the runtime
> implementation won't work at compile time, and it's up to the programmer to
> make sure that the function does what it's supposed to at both compile time
> and runtime. The compiler can't possibly enforce that.

Thus we're in a situation where pure means pure only by convention, not because it's enforced by the compiler. It's like const in c++ then, it's const only by convention, only because people promise that they're not going to mutate it. I don't like rules that are enforced only by everybody relying on good manners.