On 2013-04-11 12:09, Simen Kjærås wrote:

> That's not the point. The point is, if he'd written this:
>
>    strong pure bar(int* n) { ... }
>
> The compiler would have said 'Bad programmer! int* is not implicitly
> castable to immutable!'

What's the point of that. Just have "strong" mean const/immutable parameters.

-- 
/Jacob Carlborg

On 04/11/2013 03:29 PM, Jacob Carlborg wrote:
> What's the point of that. Just have "strong" mean const/immutable parameters.

The point is to have a way for me, the programmer, to say to the compiler: "I mean for this function to be strongly pure, can you confirm whether my choice of function inputs supports this please?"

On 11 April 2013 11:09, Simen Kjærås <simen.kjaras@gmail.com> wrote:

> On Thu, 11 Apr 2013 12:03:38 +0200, deadalnix <deadalnix@gmail.com> wrote:
>
>  On Thursday, 11 April 2013 at 08:36:13 UTC, Joseph Rushton Wakeling wrote:
>>
>>> On 04/10/2013 08:39 PM, Walter Bright wrote:
>>>
>>>> Sure there is. Declare the function as pure, and the function's
>>>> parameters as
>>>> const or immutable.
>>>>
>>>
>>> Sure, I accept that.  What I was meaning, though, was an up-front
>>> declaration
>>> which would make the compiler shout if those necessary conditions were
>>> not met.
>>>
>>> i.e.
>>>
>>>        pure foo(int n) { ... }     // compiles
>>>
>>>        strong pure bar(int n) { ... } // compiler instructs you to make
>>>                                       // variables const or immutable
>>>
>>
>> Both are strongly pure.
>>
>
> That's not the point. The point is, if he'd written this:
>
>   strong pure bar(int* n) { ... }
>
> The compiler would have said 'Bad programmer! int* is not implicitly castable to immutable!'
>

Great, just what we need.  A compiler that barrages the user about how bad his code is, then dies...

</sarcasm>

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 11 April 2013 14:38, Joseph Rushton Wakeling < joseph.wakeling@webdrake.net> wrote:

> On 04/11/2013 03:29 PM, Jacob Carlborg wrote:
> > What's the point of that. Just have "strong" mean const/immutable
> parameters.
>
> The point is to have a way for me, the programmer, to say to the compiler:
> "I
> mean for this function to be strongly pure, can you confirm whether my
> choice of
> function inputs supports this please?"
>

I think that giving the user choice of purity is about as useful as given user choice over what functions should be inlined, or what vars should go in registers.

Such decisions are best left to the compiler devs judgement on doing the right thing for you.  Even if they sometimes get it wrong. :o)

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On 04/11/2013 03:49 PM, Iain Buclaw wrote:
> Great, just what we need.  A compiler that barrages the user about how bad his code is, then dies...

"Compiler says no ..."

On 04/11/2013 03:53 PM, Iain Buclaw wrote:
> I think that giving the user choice of purity is about as useful as given user choice over what functions should be inlined, or what vars should go in registers.

Well, I don't mean the compiler should guarantee that my code will be optimized in a certain way, but it's handy to be able to verify that it _qualifies_ for those optimizations.

That said, I think my suggestion is a minor convenience feature, and is much, much less important than ironing out the design/implementation issues that others have raised in this thread.

> Such decisions are best left to the compiler devs judgement on doing the right thing for you.  Even if they sometimes get it wrong. :o)

What??!!  You guys get it wrong sometimes??!! :-O

On 4/11/2013 3:02 AM, deadalnix wrote:
> On Thursday, 11 April 2013 at 00:41:01 UTC, Walter Bright wrote:
>> On 4/10/2013 5:33 PM, deadalnix wrote:
>>> call with const parameter can be considered strongly pure if the argument is
>>> immutable
>>
>> The argument doesn't need to be immutable because nobody can change it while
>> the function is running.
>
> I explained the sentence just above how it is possible. Ignoring issue rarely
> help when it come to solve them.

The delegate issue is a known one, and can be solved, and is not relevant to this point.

On 2013-04-11 15:53, Iain Buclaw wrote:

> I think that giving the user choice of purity is about as useful as
> given user choice over what functions should be inlined, or what vars
> should go in registers.
>
> Such decisions are best left to the compiler devs judgement on doing the
> right thing for you.  Even if they sometimes get it wrong. :o)

Beside from optimizations, it could good to be able to mark functions as pure, form a design point of view. I might be more easy to reason about a piece of code.

-- 
/Jacob Carlborg

On 2013-04-11 15:38, Joseph Rushton Wakeling wrote:

> The point is to have a way for me, the programmer, to say to the compiler: "I
> mean for this function to be strongly pure, can you confirm whether my choice of
> function inputs supports this please?"

Why should I have to explicitly specify "immutable" when that could be default for strongly pure functions?

-- 
/Jacob Carlborg

On 04/11/2013 07:48 AM, Walter Bright wrote:
> On 4/10/2013 10:44 PM, Timon Gehr wrote:
>> On 04/10/2013 11:50 PM, Walter Bright wrote:
>>> ...
>>>
>>> My point was that competing designs are very probably not necessary. We
>>> just need to pull on the string on what must be.
>>>
>>
>> Yes, IMO it is quite obvious how to do it. (transfer the meaning of the
>> modifiers from member functions to local functions, disallow
>> conversion to const
>> for delegates and disallow loading a mutable delegate from a const
>> receiver.)
>> However, I think there are other opinions. There will probably always
>> be as long
>> as nothing is specified as the official behaviour.
>
> A delegate works exactly like a member function call. It has an implicit
> 'this' pointer, and how the 'this' pointer is qualified, just like for a
> member function, determines how it works.

That's still not sufficient as a specification.

A member function may be qualified differently from the 'this' pointer and calling said member function may even be disallowed because of this.

For delegates, the same syntax element is used for qualifying the context pointer and the function. Therefore delegates and member functions need to behave differently.