On Tue, 13 Mar 2012 04:40:01 +0100, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> 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

Adding a special case for AAs is not a good idea but
these operators are indeed special and should have
a defined behavior.
Requiring pureness for comparison for example is good
for all kind of generic algorithms.

Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> On 3/13/12 6:02 AM, Peter Alexander wrote:
>> 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.
> 
> Because in the general case functions call one another so there's no way to figure which to look at first.
> 
> Andrei

That's no difference from template functions calling each others right?

    int a()(int x) { return x==0?1:b(x-1); }
    int b()(int x) { return x==0?1:a(x-1); }

On 3/13/2012 4:15 AM, Don Clugston wrote:
> On 13/03/12 03:05, Walter Bright wrote:
>> On 3/12/2012 6:15 PM, Stewart Gordon wrote:
>>> And what about toString?
>>
>> Good question. What do you suggest?
>
> Why can't we just kill that abomination?

Break a lot of existing code?

On 03/13/2012 11:39 PM, kennytm wrote:
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> On 3/13/12 6:02 AM, Peter Alexander wrote:
>>> 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.
>>
>> Because in the general case functions call one another so there's no way
>> to figure which to look at first.
>>
>> Andrei
>
> That's no difference from template functions calling each others right?
>
>      int a()(int x) { return x==0?1:b(x-1); }
>      int b()(int x) { return x==0?1:a(x-1); }

http://d.puremagic.com/issues/show_bug.cgi?id=7205

The non-trivial issue is what to do with compile-time reflection in the function body. I think during reflection, the function should appear non-annotated to itself and all functions with inferred attributes it calls transitively through other functions with inferred attributes regardless of whether or not they are later inferred. (currently inference fails spectacularly for anything inside a typeof expression anyway, therefore it is not yet that much of an issue.)

pragma(msg, typeof({writeln("hello world");})); // "void function() pure @safe"

Walter:

> Break a lot of existing code?

Invent a good deprecation strategy for toString?

The idea of modifying toString isn't new, we have discussed it more than on time, and I agree with the general strategy Don appreciates. As far as I know you didn't do much on it mostly because there were other more important things to do, like fixing important bugs, not because people thought the situation was good enough. Maybe now it's a good moment to slow down bug fixing and look for things more important than bugs (where "important" means "can't be done much later").

Bye,
bearophile

On 3/13/12 5:39 PM, kennytm wrote:
> Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org>  wrote:
>> Because in the general case functions call one another so there's no way
>> to figure which to look at first.
>>
>> Andrei
>
> That's no difference from template functions calling each others right?
>
>      int a()(int x) { return x==0?1:b(x-1); }
>      int b()(int x) { return x==0?1:a(x-1); }

There is. Templates are guaranteed to have the body available. Walter uses a recursive on-demand approach instead of a worklist approach for inferring attributes (worklists have an issue I forgot about).

Andrei

On 3/13/2012 4:50 AM, Martin Nowak wrote:
> Yeah, you're right. It would easily create confusing behavior.

In general, for modules a and b, all of these should work:

dmd a b

dmd b a

dmd -c a
dmd -c b

On 13 March 2012 04:15, H. S. Teoh <hsteoh@quickfur.ath.cx> 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.
>

MMMmmm, now we're talking!
I've always preferred this approach :P

On 14.03.2012 3:23, Walter Bright wrote:
> On 3/13/2012 4:15 AM, Don Clugston wrote:
>> On 13/03/12 03:05, Walter Bright wrote:
>>> On 3/12/2012 6:15 PM, Stewart Gordon wrote:
>>>> And what about toString?
>>>
>>> Good question. What do you suggest?
>>
>> Why can't we just kill that abomination?
>
> Break a lot of existing code?

And gain efficiency. BTW transition paths were suggested, need to just dig up DIP9 discussions.

-- 
Dmitry Olshansky

> In general, for modules a and b, all of these should work:
>
> dmd a b
>
> dmd b a
>
> dmd -c a
> dmd -c b

For '-c' CTFE will already run semantic3 on the other module's functions.
But it would be very inefficient to do that for attributes.