View mode: basic / threaded / horizontal-split · Log in · Help
March 11, 2012
toHash => pure, nothrow, const, @safe
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).
March 11, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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.
March 12, 2012
Re: toHash => pure, nothrow, const, @safe
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)
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home