View mode: basic / threaded / horizontal-split · Log in · Help
February 16, 2012
Object.opEquals, opCmp, toHash
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.).
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.).
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.
February 16, 2012
Re: Object.opEquals, opCmp, toHash
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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home