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.

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

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.

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.

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!'

-- 
Simen

On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix 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.

is foo strongly pure because of n being a value type that cannot contain any indirection? (i.e. as far as the outside world is concerned you don't get any side effects whatever you do with it).

Is the same for structs that contain no indirection? Or do they have to be const/immutable?

2013/4/11 John Colvin <john.loughran.colvin@gmail.com>

> On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix 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.
>>
>
> is foo strongly pure because of n being a value type that cannot contain any indirection? (i.e. as far as the outside world is concerned you don't get any side effects whatever you do with it).
>
> Is the same for structs that contain no indirection? Or do they have to be const/immutable?
>

It is same for structs that has no *mutable* indirections. In below, all functions are strongly pure.

module x;
struct S1 { int n; }
struct S2 { immutable int[] arr; }
struct S3 { int[] arr; }

pure int foo0(int n);
pure int foo1(S1);   // S1 has no indirections
pure int foo2(S2);   // S2 has no *mutable* indirections
pure int foo3(immutable ref S3 x);   // foo3 cannot access any mutable
indirections

Kenji Hara

On Thursday, 11 April 2013 at 10:27:55 UTC, kenji hara wrote:
> 2013/4/11 John Colvin <john.loughran.colvin@gmail.com>
>
>> On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix 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.
>>>
>>
>> is foo strongly pure because of n being a value type that cannot contain
>> any indirection? (i.e. as far as the outside world is concerned you don't
>> get any side effects whatever you do with it).
>>
>> Is the same for structs that contain no indirection? Or do they have to be
>> const/immutable?
>>
>
> It is same for structs that has no *mutable* indirections. In below, all
> functions are strongly pure.
>
> module x;
> struct S1 { int n; }
> struct S2 { immutable int[] arr; }
> struct S3 { int[] arr; }
>
> pure int foo0(int n);
> pure int foo1(S1);   // S1 has no indirections
> pure int foo2(S2);   // S2 has no *mutable* indirections
> pure int foo3(immutable ref S3 x);   // foo3 cannot access any mutable
> indirections
>
> Kenji Hara

right, gotcha!

On 04/11/2013 12:03 PM, deadalnix wrote:
> Both are strongly pure.

Perhaps the fact that I can have this misunderstanding is itself an argument for an explicit "strong pure" keyword, so that a daft bugger like me can really be sure he's getting what he thinks he's getting? :-)

Apart from that, I think Simen replied better than I could ...

On Thursday, 11 April 2013 at 10:16:39 UTC, John Colvin wrote:
> On Thursday, 11 April 2013 at 10:03:39 UTC, deadalnix 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.
>
> is foo strongly pure because of n being a value type that cannot contain any indirection? (i.e. as far as the outside world is concerned you don't get any side effects whatever you do with it).
>
> Is the same for structs that contain no indirection? Or do they have to be const/immutable?

I don't know what the current implementation says, but it should be.