On Monday, October 01, 2012 08:25:39 Tommi wrote:
> 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.

No. We're not in that situation at all. The function will do the same thing with every call at compile time, and it will do the same thing with every call at runtime. It's like you're complaining about the fact that a function on a big endian machine doesn't do exactly the same thing as when it's compiled for a little endian machine. It's being compiled for a different environment, so its behavior can change. __ctfe really isn't all that different from static if or version blocks which effectively result in different functions depending on how or where the code is compiled.

What isn't enforced is that the function does the same thing at compile time as at runtime, and you can't enforce that any more than you can enforce that it does the same thing on one machine as another when they have different architectures or OSes or whatot. By using __ctfe, you are providing an alternate implementation for compile time just like you could provide alternate implementations for different OSes or architectures.

- Jonathan M Davis

On Sunday, September 30, 2012 23:38:43 Jonathan M Davis wrote:
> On Monday, October 01, 2012 08:25:39 Tommi wrote:
> > 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.
> 
> No. We're not in that situation at all. The function will do the same thing with every call at compile time, and it will do the same thing with every call at runtime. It's like you're complaining about the fact that a function on a big endian machine doesn't do exactly the same thing as when it's compiled for a little endian machine. It's being compiled for a different environment, so its behavior can change. __ctfe really isn't all that different from static if or version blocks which effectively result in different functions depending on how or where the code is compiled.
> 
> What isn't enforced is that the function does the same thing at compile time as at runtime, and you can't enforce that any more than you can enforce that it does the same thing on one machine as another when they have different architectures or OSes or whatot. By using __ctfe, you are providing an alternate implementation for compile time just like you could provide alternate implementations for different OSes or architectures.

While __ctfe is not used in a static if, that's effectively the behavior that it has. You're basically complaining about how these two functions don't return the same value:

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

They're effectively completely different functions that share the same name (and presumably the same intent), but they're implementations are different, and it's obviously up to the programmer to make sure that they do what they're supposed to do. It has _nothing_ to do with pure.

- Jonathan M Davis

On 10/1/12 2:19 AM, Tommi wrote:
> 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.

Don't want to sound dismissive, but the short answer is there is no problem.

Andrei

I'll have to consider all functions potentially schizophrenic then. They might do one thing at compile-time and another at run-time.

I was going to make a feature request to add a compiler flag for making more functions execute at compile-time than those which the compiler *has* to. But this __ctfe thing renders that impossible.

On Monday, 1 October 2012 at 06:25:19 UTC, Tommi wrote:
> 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.

The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it.

On Monday, October 01, 2012 09:46:43 Tommi wrote:
> I'll have to consider all functions potentially schizophrenic then. They might do one thing at compile-time and another at run-time.

That's only the case if they're buggy, so that's pretty much the same as considering all functions potentially buggy.

> I was going to make a feature request to add a compiler flag for making more functions execute at compile-time than those which the compiler *has* to. But this __ctfe thing renders that impossible.

I have no idea how you could possibly use a compiler flag for that, whether __ctfe or not. It really doesn't make sense to try and make functions in general run at compile time. Most of the time, functions need to be run at runtime, otherwise you wouldn't even need to generate an executable, just a result. And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an instance of the halting problem. So, it really doesn't make sense to have the compiler trying to evaluate functions at compile time when it hasn't been explicitly told to.

And it works just fine to assign the result of a function call to enum if you want a specific function call to be executed at compile time, so I really don't think that this is an issue anyway.

- Jonathan M Davis

Le 01/10/2012 08:07, Jonathan M Davis a écrit :
> 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

Or that : http://klickverbot.at/blog/2012/05/purity-in-d/

On Mon, 01 Oct 2012 01:40:37 -0400, Tommi <tommitissari@hotmail.com> 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();
> }

You have a bug in your code, here let me fix that for you:

> int pow2(int val) pure
> {
>     return val * val;
> }

OK, on to the next thread...

-Steve

On Monday, 1 October 2012 at 08:04:49 UTC, Jonathan M Davis wrote:
> And you _can't_ determine ahead of time which functions can be safely executed at compile time either, because that's an
> instance of the halting problem.

I don't understand (I did read what "halting problem" means just now, but I still don't understand). If there was no __ctfe variable, and thus a guarantee that all functions do the same thing at compile-time and run-time, couldn't the compiler just try aggressively to execute all function calls at compile-time? Obviously it wouldn't bother trying CTFE for function calls that had arguments which weren't evaluable at compile-time. Nor would it bother with functions that it knows have memory allocations or other limitations of CTFE.

If not a compiler flag, then it could be a function attribute. Just like c++ function attribute constexpr, which guarantees that the function executes at compile time given you provide it with compile-time evaluable arguments (and there are limitations to what the function can do). Why wouldn't this attribute be possible with D?

On Monday, 1 October 2012 at 08:00:47 UTC, Jakob Ovrum wrote:
>
> The only real problem here is that you wrote a function called pow2 that effectively returns 6 unconditionally. I doubt your math professor would be particularly impressed. If you had used __ctfe properly, it would return the same value both at compile-time and runtime. At present, __ctfe is a necessary evil as CTFE can be severely crippled without it.

I solemnly swear not to use __ctfe improperly. But my problem with it is, that there *exists* the possibility of improper use of __ctfe.

Plus, I just realized, I've never actually met any math professor. I never went to a university (nor study programming for that matter).