On 4/9/2013 5:56 AM, Andrei Alexandrescu wrote:
> s/body/signature/
> s/Crap/Awesome/

I agree that the notions of strong/weak purity are awesome, I believe they are a D innovation, and if I recall correctly this innovation is thanks to Don Clugston, one of our most awesome contributors.

On 4/9/2013 6:49 AM, Dicebot wrote:
> Not gonna argue latter but former is just wrong.
>
> struct Test
> {
>      int a;
>      pure int foo1() // strong pure
>      {
>          return 42;
>      }
>
>      pure int foo2() // weak pure
>      {
>          return a++;
>      }
> }
>
> Signature is the same for both functions.

foo1 is weakly pure. It would be strongly pure if it were declared:

    const pure int foo1();

On 4/9/2013 7:50 AM, Simen Kjærås wrote:
> It's based purely on function signature

Correct.

(I should point out that there are cases where the compiler infers purity from the function body:

1. lambdas
2. template functions
3. auto functions
)

On 4/9/2013 7:12 AM, Simen Kjærås wrote:
> const is not sufficient, as someone else might have a mutable
> reference. immutable is needed.

const is sufficient for strongly pure, because another reference is not available to the function body, and so the function cannot mutate it.

On 4/9/2013 3:52 AM, Joseph Rushton Wakeling wrote:
> I do agree that it's a great pity there is not a way to declare strong purity
> for D functions.

Sure there is. Declare the function as pure, and the function's parameters as const or immutable.

On 4/9/2013 12:52 AM, Manu wrote:
> But that's meaningless though, because there's always the possibility that
> something somewhere else may have a non-const reference to that thing.
> Can you suggest a case where const could EVER be used in any sort of optimisation?

Sure:

   pure int bar(const int*);

   int foo(int* pt) {
       int t = *pt;   // (1)
       int x = bar(&t);
       return t +       // guaranteed to be same value as (1)
            x;
   }

But the main purpose of const is so that you can have a single function that can operate on both mutable and immutable references. Otherwise, you'd have to do the copy/pasta two-step and write two functions.

On 4/9/2013 1:00 AM, Manu wrote:
> Locals or allocated memory are not thread-local, can be passed wherever they
> want, including other threads.

Not unless they are marked as "shared".

On 4/9/2013 3:48 AM, deadalnix wrote:
> No, D have holes in its type system and so can't ensure anything. It has been
> show many many many times, especially by Timon and myself, and I'm kind of fed
> up to have to repeat that again and again, especiallt since fix proposal have
> recieved no attention at all.
>
> Stop claiming that such possibility exists, or take a serious look at how to
> really ensure it.

Having a bug in the compiler doesn't mean the language design is full of holes.

On 4/10/13 2:54 PM, Walter Bright wrote:
> On 4/9/2013 3:48 AM, deadalnix wrote:
>> No, D have holes in its type system and so can't ensure anything. It
>> has been
>> show many many many times, especially by Timon and myself, and I'm
>> kind of fed
>> up to have to repeat that again and again, especiallt since fix
>> proposal have
>> recieved no attention at all.
>>
>> Stop claiming that such possibility exists, or take a serious look at
>> how to
>> really ensure it.
>
> Having a bug in the compiler doesn't mean the language design is full of
> holes.

Unfortunately we have holes in the language definition, too. We can't afford to be glib about them.

Andrei

On 04/10/2013 08:54 PM, Walter Bright wrote:
> On 4/9/2013 3:48 AM, deadalnix wrote:
>> No, D have holes in its type system and so can't ensure anything. It
>> has been
>> show many many many times, especially by Timon and myself, and I'm
>> kind of fed
>> up to have to repeat that again and again, especiallt since fix
>> proposal have
>> recieved no attention at all.
>>
>> Stop claiming that such possibility exists, or take a serious look at
>> how to
>> really ensure it.
>
> Having a bug in the compiler doesn't mean the language design is full of
> holes.

Generally it does not, but is it actually not full of holes in this case? Can you give a short wrap-up of what the original language design is for type checking delegate context pointers? We can only guess, because it is not specified and much of what DMD does there is obviously buggy. In the end, we'll be left with three compiler front ends that implement three distinct competing designs.