View mode: basic / threaded / horizontal-split · Log in · Help
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On Mon, Mar 12, 2012 at 09:27:41PM -0400, Jonathan M Davis wrote:
> On Tuesday, March 13, 2012 01:15:59 Stewart Gordon wrote:
> > On 11/03/2012 23: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);
> > 
> > <snip>
> > 
> > And what about toString?
> 
> That really should be too, but work is probably going to have to be done to 
> make sure that format and std.conv.to can be pure, since they're pretty much 
> required in most toString functions.

This is not going to be a choice, because some overrides of toHash calls
toString.


> I believe that changes to toUTF8, toUTF16, and toUTF32 were made
> recently which are at least a major step in that direction for
> std.conv.to (since it uses them) and may outright make it so that it
> can be pure now (I'm not sure if anything else is preventing them from
> being pure). But I have no idea what the current state of format is
> with regards to purity, and if the changes to toUTFx weren't enough to
> make std.conv.to pure for strings, then more will need to be done
> there as well.
[...]

Looks like we need a massive one-shot overhaul of almost all of druntime
and a potentially large part of phobos in order to get this
pure/@safe/nothrow thing off the ground.  There are just too many
interdependencies everywhere that there's practically no way to do it
incrementally. I tried the incremental approach several times and have
given up, 'cos every small change inevitably propagates to functions all
over druntime and then some.

And I'm not talking about doing just toHash, or just toString either.
Any of these functions have complex interdependencies with each other,
so it's either fix them ALL, or not at all.


T

-- 
Obviously, some things aren't very obvious.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On 3/12/2012 6:15 PM, Stewart Gordon wrote:
> And what about toString?

Good question. What do you suggest?
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On 3/12/2012 6:40 PM, H. S. Teoh wrote:
> And I'm not talking about doing just toHash, or just toString either.
> Any of these functions have complex interdependencies with each other,
> so it's either fix them ALL, or not at all.

Yup. It also seems very hard to figure out a transitional path to it.
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On Mon, Mar 12, 2012 at 07:06:51PM -0700, Walter Bright wrote:
> On 3/12/2012 6:40 PM, H. S. Teoh wrote:
> >And I'm not talking about doing just toHash, or just toString either.
> >Any of these functions have complex interdependencies with each
> >other, so it's either fix them ALL, or not at all.
> 
> Yup. It also seems very hard to figure out a transitional path to it.

Perhaps we just need to bite the bullet and do it all in one shot and
check it into master, then deal with the aftermath later. :-) Otherwise
it will simply never get off the ground.


T

-- 
Two wrongs don't make a right; but three rights do make a left...
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On 13-03-2012 03:15, H. S. Teoh wrote:
> On Mon, Mar 12, 2012 at 07:06:51PM -0700, Walter Bright wrote:
>> On 3/12/2012 6:40 PM, H. S. Teoh wrote:
>>> And I'm not talking about doing just toHash, or just toString either.
>>> Any of these functions have complex interdependencies with each
>>> other, so it's either fix them ALL, or not at all.
>>
>> Yup. It also seems very hard to figure out a transitional path to it.
>
> Perhaps we just need to bite the bullet and do it all in one shot and
> check it into master, then deal with the aftermath later. :-) Otherwise
> it will simply never get off the ground.
>
>
> T
>

I have to say this seems like the most sensible approach right now.

-- 
- Alex
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
Walter:

> Good question. What do you suggest?

I suggest to follow a slow but reliable path, working bottom-up: turn to!string()/text()/format() into pure+nothrow functions, and then later require toString to be pure+nothrow and to have such annotations.

Bye,
bearophile
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On 3/12/12 8:15 PM, Stewart Gordon wrote:
> On 11/03/2012 23: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);
> <snip>
>
> And what about toString?

I think the three others have a special regime because pointers to them 
must be saved for the sake of associative arrays. toString is used only 
generically,

Andrei
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On Mon, Mar 12, 2012 at 10:58:18PM -0400, bearophile wrote:
> Walter:
> 
> > Good question. What do you suggest?
> 
> I suggest to follow a slow but reliable path, working bottom-up: turn
> to!string()/text()/format() into pure+nothrow functions, and then
> later require toString to be pure+nothrow and to have such
> annotations.
[...]

The problem is that there may not *be* a bottom to start from. These
functions are all interlinked to each other in various places (spread
across a myriad of different overrides of them). I've tried to find one
function that I can annotate without needing hundreds of other changes,
but alas, they all depend on each other at some level, and every time I
end up annotating almost every other function in druntime and the change
just gets bigger and bigger.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On 2012-03-13 01:40, Walter Bright wrote:
> On 3/12/2012 1:56 PM, Martin Nowak wrote:
>> It doesn't require all source code.
>> It just means that without source code nothing can be inferred and the
>> attributes fall back to what has been annotated by hand.
>
> Hello endless bug reports of the form:
>
> "It compiles when I send the arguments to dmd this way but not that way.
> dmd is broken. D sux."

We already have that, sometimes :(

-- 
/Jacob Carlborg
March 13, 2012
Re: toHash => pure, nothrow, const, @safe
On Monday, 12 March 2012 at 09:40:15 UTC, Walter Bright wrote:
> On 3/12/2012 1:08 AM, Martin Nowak wrote:
>> What's wrong with auto-inference. Inferred attributes are only 
>> strengthening
>> guarantees.
>
> Auto-inference is currently done for lambdas and template 
> functions - why? - because the function's implementation is 
> guaranteed to be visible to the compiler. For other functions, 
> not so, and so the attributes must be part of the function 
> signature.

Dumb question:

Why not auto-infer when the function body is available, and put 
the inferred attributes into the automatically generated .di file?

Apologies if I've missed something completely obvious.
2 3 4 5 6 7 8 9
Top | Discussion index | About this forum | D home