On 4/10/2013 12:43 PM, Timon Gehr wrote:
> 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.

Clearly, delegates should not be able to break purity, const, shared, etc. Any setup that allows that is broken.

On 4/10/13 5:25 PM, Walter Bright wrote:
> On 4/10/2013 12:43 PM, Timon Gehr wrote:
>> 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.
>
> Clearly, delegates should not be able to break purity, const, shared,
> etc. Any setup that allows that is broken.

Yah, hence the holes :o). I think it's important to acknowledge that problems in the language definition exist and problems in the language implementation also exist. Both are important, but the former are more so because fixing them makes it possible to fix many of the implementation issues.

Andrei

On 4/10/2013 2:28 PM, Andrei Alexandrescu wrote:
> On 4/10/13 5:25 PM, Walter Bright wrote:
>> On 4/10/2013 12:43 PM, Timon Gehr wrote:
>>> 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.
>>
>> Clearly, delegates should not be able to break purity, const, shared,
>> etc. Any setup that allows that is broken.
>
> Yah, hence the holes :o). I think it's important to acknowledge that problems in
> the language definition exist and problems in the language implementation also
> exist. Both are important, but the former are more so because fixing them makes
> it possible to fix many of the implementation issues.


My point was that competing designs are very probably not necessary. We just need to pull on the string on what must be.

On Wednesday, 10 April 2013 at 17:12:27 UTC, Dicebot wrote:
> On Wednesday, 10 April 2013 at 15:52:23 UTC, deadalnix wrote:
>> ...
>
> And that is exactly what makes it useless. I need one keyword to automatically verify for me that parameters fine, that context is fine, return value is fine etc. This is the basic crucial concept and everything else should be built on top of it, not other way around. No one can say that my function is pure just by seeing keyword because I have probably forgot something. It is like saying that immutable is immutable only if you take care of some cases. Outstanding issue in my opinion.

Then you'd need 2 keyword, and one would be completely redundant with information already present in the signature.

On Wednesday, 10 April 2013 at 18:33:26 UTC, Walter Bright wrote:
> 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.

No !

A delegate reached via parameters and called can mute them.

call with const parameter can be considered strongly pure if the argument is immutable (granted we fix delegate transitivity issues).

On Wednesday, 10 April 2013 at 18:54:15 UTC, 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.

It is not about compiler bugs, it is about language definition. The issue has been explained over and over again, and DIP has been made about it already.

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.

On Wednesday, 10 April 2013 at 18:24:22 UTC, Walter Bright wrote:
> On 4/9/2013 1:33 AM, Manu wrote:
>> How can 'weak pure' reasonably be called any kind of 'pure'? It's not pure at
>> all. The function returns a completely different result when called twice.
>> That's the definition of not-pure.
>> I suggest that no D language newbie would ever reasonably expect that behaviour.
>
> I explained it in another reply here.
>
> I agree that it is initially confusing. I was myself confused about it until Don set me straight!

For some reason I was never confused by this issue, even though I'm clearly in the minority. I always thought 'pure' set up an isolated set of instructions which only behaved according to what it was given. So if I found out it could modify by reference, it didn't shake my basic idea of what it was supposed to do. As long as it modified in exactly the same way, it still seemed like a separate and predictable box.

On 04/11/2013 02:41 AM, 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.
>

(He has written DIP30. Under DIP30 this would no longer be the case.)

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.