On 2/16/2012 3:12 AM, Daniel Murphy wrote:
> I mean, are we going to have a shared overload in Object for each of those
> functions?

No.

On 2/16/2012 7:52 AM, Timon Gehr wrote:
> So imo, making opEquals, opCmp, toHash const pure nothrow @safe is blocked by
> properly annotating Phobos as well as the following issues:
>
> Bugs in existing attribute inference:
> http://d.puremagic.com/issues/show_bug.cgi?id=7205
> http://d.puremagic.com/issues/show_bug.cgi?id=7511
>
> Enhancement required for making templates const correct:
> http://d.puremagic.com/issues/show_bug.cgi?id=7521

Yes, I want to get all that fixed.

>> One reason is memoization, aka lazy initialization, aka logical const. I
>> don't believe these are worth it. If you must do it inside those
>> functions (and functions that override them), you're on your own to make
>> it work right (use unsafe casts, etc.).
>
> It would be helpful if we could add cast(pure) for that purpose. The
> documentation could state that cast(pure) is only valid if the behaviour of the
> enclosing function still appears to be pure.

cast(pure) sounds like a good idea.

On 16.02.2012 20:10, H. S. Teoh wrote:
> On Thu, Feb 16, 2012 at 01:53:46PM -0500, Jonathan M Davis wrote:
>> On Thursday, February 16, 2012 09:38:54 H. S. Teoh wrote:
>>> This is a non-problem once the compiler implements memoization as an
>>> optimisation. Which it can't until we go ahead with this change.
>>> This is the direction that we *should* be going anyway, so why not
>>> do it now rather than later?
>>
>> I would point out that there are no plans to implement any kind of
>> memoization in the language or compiler. Also, while it can help
>> performance, it can also _harm_ performance. So having it controlled
>> by the compiler is not necessarily a great idea anyway. It's really
>> the sort of thing that should involve profiling on the part of the
>> programmer.
> [...]
>
> Then I agree with bearophile that we should have @memoize (or its
> negation), so that the programmer can indicate to the compiler that the
> function should be memoized (or not).

Unfortunately, that's too simple. Although the compiler can memoize a few simple cases, it can't do it efficiently in general.

Sometimes it makes sense to store the memoized result in the object, sometimes separately. Sometimes only certain cases should be memoized --
the question of whether to memoize or not may depend on the value of the object (you only want to memoize the complicated cases).
It's too hard for the poor compiler.

On Thursday, 16 February 2012 at 21:05:19 UTC, Don wrote:
> On 16.02.2012 20:10, H. S. Teoh wrote:
>> On Thu, Feb 16, 2012 at 01:53:46PM -0500, Jonathan M Davis wrote:
>>> On Thursday, February 16, 2012 09:38:54 H. S. Teoh wrote:
>>>> This is a non-problem once the compiler implements memoization as an
>>>> optimisation. Which it can't until we go ahead with this change.
>>>> This is the direction that we *should* be going anyway, so why not
>>>> do it now rather than later?
>>>
>>> I would point out that there are no plans to implement any kind of
>>> memoization in the language or compiler. Also, while it can help
>>> performance, it can also _harm_ performance. So having it controlled
>>> by the compiler is not necessarily a great idea anyway. It's really
>>> the sort of thing that should involve profiling on the part of the
>>> programmer.
>> [...]
>>
>> Then I agree with bearophile that we should have @memoize (or its
>> negation), so that the programmer can indicate to the compiler that the
>> function should be memoized (or not).
>
> Unfortunately, that's too simple. Although the compiler can memoize a few simple cases, it can't do it efficiently in general.
>
> Sometimes it makes sense to store the memoized result in the object, sometimes separately. Sometimes only certain cases should be memoized --
> the question of whether to memoize or not may depend on the value of the object (you only want to memoize the complicated cases).
> It's too hard for the poor compiler.

I'll add to Don's comment a question: Compile-time memoization means the decision is static. Shouldn't the decision tough be made instead at run-time to account for the run-time characteristics of the process? E.g. memoize the frequent case. This sounds to me more in the realm of a JVM optimization rather than a compiler one.