Consider the toHash() function for struct key types:

http://dlang.org/hash-map.html

And of course the others:

const hash_t toHash();
const bool opEquals(ref const KeyType s);
const int opCmp(ref const KeyType s);

They need to be, as well as const, pure nothrow @safe.

The problem is:
1. a lot of code must be retrofitted
2. it's just plain annoying to annotate them

It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones.

So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted).

On 12-03-2012 00:54, Walter Bright wrote:
> Consider the toHash() function for struct key types:
>
> http://dlang.org/hash-map.html
>
> And of course the others:
>
> const hash_t toHash();
> const bool opEquals(ref const KeyType s);
> const int opCmp(ref const KeyType s);
>
> They need to be, as well as const, pure nothrow @safe.
>
> The problem is:
> 1. a lot of code must be retrofitted
> 2. it's just plain annoying to annotate them
>
> It's the same problem as for Object.toHash(). That was addressed by
> making those attributes inheritable, but that won't work for struct ones.
>
> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as
> struct members be automatically annotated with pure, nothrow, and @safe
> (if not already marked as @trusted).

It may be a hack, but you know, those have special semantics/meanings in the first place, so is it really that bad? Consider also that contract blocks are now implicitly const, etc.

-- 
- Alex

Walter:

> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted).

Recently I have suggested to deprecate and later remove the need of opCmp for the built-in AAs.

Regarding this hack proposal of yours, I don't fully understand its consequences yet. What are the negative sides of this idea?

Bye,
bearophile

On Sunday, 11 March 2012 at 23:55:34 UTC, Alex Rønne Petersen wrote:
> It may be a hack, but you know, those have special semantics/meanings in the first place, so is it really that bad? Consider also that contract blocks are now implicitly const, etc.

Agreed. Those are already special, so I don't think it hurts to make this change. But I may be missing some implications.

Kapps:

> Agreed. Those are already special, so I don't think it hurts to make this change. But I may be missing some implications.

At risk of sounding like a troll, I hope from now on Walter will not use this kind of strategy to solve all the MANY breaking changes D/DMD will need to face :-)

Bye,
bearophile

On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
> Consider the toHash() function for struct key types:
> 
> http://dlang.org/hash-map.html
> 
> And of course the others:
> 
> const hash_t toHash();
> const bool opEquals(ref const KeyType s);
> const int opCmp(ref const KeyType s);
> 
> They need to be, as well as const, pure nothrow @safe.
> 
> The problem is:
> 1. a lot of code must be retrofitted
> 2. it's just plain annoying to annotate them

Ah, I see the "just add a new attribute" thing is coming back to bite you. ;-)


> It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones.
> 
> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted).

I'm wary of the idea of automatically-imposed attributes on a "special" set of functions... seems a bit arbitrary, and arbitrary things don't tend to stand the test of time.

OTOH I can see the value of this. Forcing all toHash's to be pure nothrow @safe makes is much easier to, for example, implement AA's purely in object_.d (which I'm trying to do :-P). You don't have to worry about somebody defining a toHash that does strange things. Same thing with opEquals, etc.. It also lets you freely annotate stuff that calls these functions as pure, nothrow, @safe, etc., without having to dig through every function in druntime and phobos to mark all of them.


Here's an alternative (and perhaps totally insane) idea: what if, instead of needing to mark functions as pure, nothrow, etc., etc., we ASSUME all functions are pure, nothrow, and @safe unless they're explicitly declared otherwise? IOW, let all D code be pure, nothrow, and @safe by default, and if you want non-pure, or throwing code, or unsafe code, then you annotate the function as impure, throwing, or @system. It goes along with D's general philosophy of safe-by-default, unsafe-if-you-want-to.

Or, as a compromise, perhaps the compiler can auto-infer most of the attributes without any further effort from the user.


T

-- 
If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher

On 12-03-2012 06:43, H. S. Teoh wrote:
> On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
>> Consider the toHash() function for struct key types:
>>
>> http://dlang.org/hash-map.html
>>
>> And of course the others:
>>
>> const hash_t toHash();
>> const bool opEquals(ref const KeyType s);
>> const int opCmp(ref const KeyType s);
>>
>> They need to be, as well as const, pure nothrow @safe.
>>
>> The problem is:
>> 1. a lot of code must be retrofitted
>> 2. it's just plain annoying to annotate them
>
> Ah, I see the "just add a new attribute" thing is coming back to bite
> you. ;-)
>
>
>> It's the same problem as for Object.toHash(). That was addressed by
>> making those attributes inheritable, but that won't work for struct
>> ones.
>>
>> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as
>> struct members be automatically annotated with pure, nothrow, and
>> @safe (if not already marked as @trusted).
>
> I'm wary of the idea of automatically-imposed attributes on a "special"
> set of functions... seems a bit arbitrary, and arbitrary things don't
> tend to stand the test of time.
>
> OTOH I can see the value of this. Forcing all toHash's to be pure
> nothrow @safe makes is much easier to, for example, implement AA's
> purely in object_.d (which I'm trying to do :-P). You don't have to
> worry about somebody defining a toHash that does strange things. Same
> thing with opEquals, etc.. It also lets you freely annotate stuff that
> calls these functions as pure, nothrow, @safe, etc., without having to
> dig through every function in druntime and phobos to mark all of them.
>
>
> Here's an alternative (and perhaps totally insane) idea: what if,
> instead of needing to mark functions as pure, nothrow, etc., etc., we
> ASSUME all functions are pure, nothrow, and @safe unless they're
> explicitly declared otherwise? IOW, let all D code be pure, nothrow, and
> @safe by default, and if you want non-pure, or throwing code, or unsafe
> code, then you annotate the function as impure, throwing, or @system. It
> goes along with D's general philosophy of safe-by-default,
> unsafe-if-you-want-to.

No. Too late in the design process. I have 20k+ lines of code that rely on the opposite behavior.

>
> Or, as a compromise, perhaps the compiler can auto-infer most of the
> attributes without any further effort from the user.

No, that has API design issues. You can silently break a guarantee you made previously.

>
>
> T
>


-- 
- Alex

On 12-03-2012 07:04, Alex Rønne Petersen wrote:
> On 12-03-2012 06:43, H. S. Teoh wrote:
>> On Sun, Mar 11, 2012 at 04:54:09PM -0700, Walter Bright wrote:
>>> Consider the toHash() function for struct key types:
>>>
>>> http://dlang.org/hash-map.html
>>>
>>> And of course the others:
>>>
>>> const hash_t toHash();
>>> const bool opEquals(ref const KeyType s);
>>> const int opCmp(ref const KeyType s);
>>>
>>> They need to be, as well as const, pure nothrow @safe.
>>>
>>> The problem is:
>>> 1. a lot of code must be retrofitted
>>> 2. it's just plain annoying to annotate them
>>
>> Ah, I see the "just add a new attribute" thing is coming back to bite
>> you. ;-)
>>
>>
>>> It's the same problem as for Object.toHash(). That was addressed by
>>> making those attributes inheritable, but that won't work for struct
>>> ones.
>>>
>>> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as
>>> struct members be automatically annotated with pure, nothrow, and
>>> @safe (if not already marked as @trusted).
>>
>> I'm wary of the idea of automatically-imposed attributes on a "special"
>> set of functions... seems a bit arbitrary, and arbitrary things don't
>> tend to stand the test of time.
>>
>> OTOH I can see the value of this. Forcing all toHash's to be pure
>> nothrow @safe makes is much easier to, for example, implement AA's
>> purely in object_.d (which I'm trying to do :-P). You don't have to
>> worry about somebody defining a toHash that does strange things. Same
>> thing with opEquals, etc.. It also lets you freely annotate stuff that
>> calls these functions as pure, nothrow, @safe, etc., without having to
>> dig through every function in druntime and phobos to mark all of them.
>>
>>
>> Here's an alternative (and perhaps totally insane) idea: what if,
>> instead of needing to mark functions as pure, nothrow, etc., etc., we
>> ASSUME all functions are pure, nothrow, and @safe unless they're
>> explicitly declared otherwise? IOW, let all D code be pure, nothrow, and
>> @safe by default, and if you want non-pure, or throwing code, or unsafe
>> code, then you annotate the function as impure, throwing, or @system. It
>> goes along with D's general philosophy of safe-by-default,
>> unsafe-if-you-want-to.
>
> No. Too late in the design process. I have 20k+ lines of code that rely
> on the opposite behavior.

I should point out that I *do* think the idea is good (i.e. if you want the "bad" things, that's what you have to declare), but it's just too late now. Also, there might be issues with const and the likes - should the system assume const or immutable or inout or...?

>
>>
>> Or, as a compromise, perhaps the compiler can auto-infer most of the
>> attributes without any further effort from the user.
>
> No, that has API design issues. You can silently break a guarantee you
> made previously.
>
>>
>>
>> T
>>
>
>


-- 
- Alex

On Sunday, 11 March 2012 at 23:54:10 UTC, Walter Bright wrote:
> Consider the toHash() function for struct key types:
>
> http://dlang.org/hash-map.html
>
> And of course the others:
>
> const hash_t toHash();
> const bool opEquals(ref const KeyType s);
> const int opCmp(ref const KeyType s);
>
> They need to be, as well as const, pure nothrow @safe.
>
> The problem is:
> 1. a lot of code must be retrofitted
> 2. it's just plain annoying to annotate them
>
> It's the same problem as for Object.toHash(). That was addressed by making those attributes inheritable, but that won't work for struct ones.
>
> So I propose instead a bit of a hack. toHash, opEquals, and opCmp as struct members be automatically annotated with pure, nothrow, and @safe (if not already marked as @trusted).

A pattern is emerging. Why not analyze it a bit and somehow try to find a common ground? Then we can generalize it to a single annotation.

On Monday, 12 March 2012 at 07:18:06 UTC, so wrote:

> A pattern is emerging. Why not analyze it a bit and somehow try to find a common ground? Then we can generalize it to a single annotation.

@mask(wat) const|pure|nothrow|safe

@wat hash_t toHash()
@wat bool opEquals(ref const KeyType s)
@wat int opCmp(ref const KeyType s)