These all need to be:

    const pure nothrow @safe

Unless this is done, the utility of const, pure, nothrow and @safe is rather crippled.

Any reason why they shouldn't be?

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.).

On Thursday, February 16, 2012 00:35:20 Walter Bright wrote:
> These all need to be:
> 
>      const pure nothrow @safe
> 
> Unless this is done, the utility of const, pure, nothrow and @safe is rather crippled.
> 
> Any reason why they shouldn't be?
> 
> 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.).

I think that that's essentially the conclusion that we as a group have come to in discussions on it in the past. The exception are those folks who don't want any of those functions to be const, because that cripples caching, lazy initialization, etc for classes. And so they argue against the whole idea. But we _have_ to make them const or, as you say, const is horribly crippled. It's one area where D's const is rather costly, but I don't see any way around it.

toString is another one, though making that pure right now just wouldn't work, because so little string stuff can pure pure (e.g. primarily because format, to, and appender aren't pure). But that really needs to be fixed anyway.

- Jonathan M Davis

I agree.  What about shared?

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jhif48$1n0n$1@digitalmars.com...
> These all need to be:
>
>     const pure nothrow @safe
>
> Unless this is done, the utility of const, pure, nothrow and @safe is rather crippled.
>
> Any reason why they shouldn't be?
>
> 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.).

On 16/02/12 09:35, Walter Bright wrote:
> These all need to be:
>
> const pure nothrow @safe
>
> Unless this is done, the utility of const, pure, nothrow and @safe is
> rather crippled.
>
> Any reason why they shouldn't be?
>
> 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.).

And if memoization has problems with these functions being const, it will have problems elsewhere.

They should be const, nothrow, @safe.
I'm less sure about pure, though. What if (for example) you have a struct which is just an index into a global table? Like a Windows handle, for example. That should still work.

On Thursday, February 16, 2012 20:30:19 Daniel Murphy wrote:
> I agree.  What about shared?

Wouldn't that require an overload? You certainly couldn't make any of them shared by default, because then they wouldn't work with non-shared objects.

- Jonathan M Davis

On 2/16/2012 1:30 AM, Daniel Murphy wrote:
> What about shared?

No! Shared is a special animal, and the user will still have to take care to deal with synchronization issues.

On 2/16/2012 1:47 AM, Don Clugston wrote:
> I'm less sure about pure, though. What if (for example) you have a struct which
> is just an index into a global table? Like a Windows handle, for example. That
> should still work.

Without pure, associative arrays cannot work reliably.

I'd suggest that if one is relying on a mutable global array, that one shouldn't use opEquals, opCmp, etc., and should use functions with other names.

I mean, are we going to have a shared overload in Object for each of those functions?

"Walter Bright" <newshound2@digitalmars.com> wrote in message news:jhikus$227j$1@digitalmars.com...
> On 2/16/2012 1:30 AM, Daniel Murphy wrote:
>> What about shared?
>
> No! Shared is a special animal, and the user will still have to take care to deal with synchronization issues.

On 16/02/2012 08:35, Walter Bright wrote:
> These all need to be:
>
> const pure nothrow @safe
>
> Unless this is done, the utility of const, pure, nothrow and @safe is rather crippled.
>
> Any reason why they shouldn't be?
>
> One reason is memoization, aka lazy initialization, aka logical const.
<snip>

But if the method is pure, the compiler can automatically implement this as an optimisation.

Stewart.

On 16/02/12 11:16, Walter Bright wrote:
> On 2/16/2012 1:47 AM, Don Clugston wrote:
>> I'm less sure about pure, though. What if (for example) you have a
>> struct which
>> is just an index into a global table? Like a Windows handle, for
>> example. That
>> should still work.
>
> Without pure, associative arrays cannot work reliably.

That's a good argument.

> I'd suggest that if one is relying on a mutable global array, that one
> shouldn't use opEquals, opCmp, etc., and should use functions with other
> names.

I would say, that the solution would be a (library) implementation of logical pure.