On Saturday, 20 April 2013 at 06:25:09 UTC, Walter Bright wrote:
> On 4/19/2013 11:12 PM, deadalnix wrote:
>> But some time, you can't alias (in case of inference for instance) and so can't choose what attribute bind to.
>
> Example, please.


Here you go:

void foo(T)(extern(C) T function() function() f);


Try making the extern(C) apply to each of:
1. the result of f()
2. the result of f()()


without breaking foo()'s type inference.

On Saturday, 20 April 2013 at 07:18:42 UTC, deadalnix wrote:
> You don't need a symbol. They also control the ABI, and this isn't always related to a specific symbol.

Well, this is how it probably should be. But looking at current D state I don't see if it was even planned. Can you have an extern without declaring some symbol at the same time within current D grammar?

On 4/20/2013 1:50 AM, Mehrdad wrote:
> On Saturday, 20 April 2013 at 06:25:09 UTC, Walter Bright wrote:
>> On 4/19/2013 11:12 PM, deadalnix wrote:
>>> But some time, you can't alias (in case of inference for instance) and so
>>> can't choose what attribute bind to.
>>
>> Example, please.
>
>
> Here you go:
>
> void foo(T)(extern(C) T function() function() f);
>
>
> Try making the extern(C) apply to each of:
> 1. the result of f()
> 2. the result of f()()
>
>
> without breaking foo()'s type inference.

What I've been trying to explain is that there's a difference between a storage class attribute and a type constructor. When pure, for example, is used as a storage class attribute, it applies to the declaration always. When pure is used as a type constructor, it applies to the type, always. There is no ambiguity about this, and no problem about choice.

For your example, for purity:

    void foo(T)(T function() pure function() pure f);

The only issue here is that extern(C) is not currently supported as a type constructor. If it were, the example would look like:

    void foo(T)(T function() extern(C) function() extern(C) f);

Again, there is no ambiguity.

On 4/20/13, Walter Bright <newshound2@digitalmars.com> wrote:
> What I've been trying to explain is that there's a difference between a
> storage
> class attribute and a type constructor.

I've mentioned this before, but we need a good definition of these on dlang.org (for example people coming from other languages like Python will have no idea what these mean).

Last time I mentioned it I didn't file a bug, but now I have: http://d.puremagic.com/issues/show_bug.cgi?id=9970

Hopefully someone with more knowledge of these can write some documentation.

On Tuesday, 16 April 2013 at 15:22:56 UTC, Andrei Alexandrescu wrote:
> There's a discussion that may be of interest to the larger community: https://github.com/D-Programming-Language/dmd/pull/1877
>
> Andrei

I just want to say I'm pretty gung-ho about the idea of attribute inference. If the interface files are blown up to their full explicit attributes, then the big problem of the PIMPL idiom could be solved, with modular programs getting all the info they need and the original source code still quite trim and easy to write. In the discussion of the possible uses of the 'scope' parameter attribute, and 'ref' safety in general, there's a lot of subtleties. One solution to the subtleties is additional attributes, which might be cumbersome to write individually, but easier if inference were on the table.

On Wednesday, April 17, 2013 12:35:07 Walter Bright wrote:
> On 4/17/2013 8:07 AM, Andrei Alexandrescu wrote:
> > On 4/16/13 4:20 PM, Peter Alexander wrote:
> >> This is the point I have a problem with:
> >>>> 2.2. One cannot opt out of nothrow or pure with auto functions.
> >>> 
> >>> This argument has one solid answer: don't use auto when the need is to specify an attribute pattern explicitly.
> >> 
> >> I find this unacceptable. Thanks to the proliferation of template code in D, it is often rather difficult to spell out return types.
> > 
> > Attribute inference is always done for templates.
> 
> And, I might add, I cannot recall a single adverse issue that has caused.

If anything, the fact that it doesn't infer more is the problem.

The primary risk is if a particular set of template arguments previously resulted in the function being pure, nothrow, or @safe but no longer do so after some code changes, and code using the template which requires pure, nothrow, or @safe then no longer compiles. But odds are that that's the fault changes to the template arguments and not the template, and requiring explict attributes wouldn't fix the problem anyway, because then you're either stuck with a combinatorial explosion of template declarations or making it so that the template always has the same set of attributes and therefore only works with code that works with that exact set of attributes.

Non-templated auto functions are not generally in the same boat, because their types are usually well-known, and therefore explicitly marking the attributes that you want works, but it may still be reasonable to do attribute inferrence for them.

- Jonathan M Davis