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.

On 3/12/2012 6:15 PM, Stewart Gordon wrote:
> And what about toString?

Good question. What do you suggest?

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.

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

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

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

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

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

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

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.