On Wednesday, 17 April 2013 at 19:06:42 UTC, Walter Bright wrote:
> On 4/17/2013 10:41 AM, Jesse Phillips wrote:
>> I wish to bring Someboddies consern to this form.
>>
>> What does attribute inference mean for inheritance?
>
>
> I specifically addressed his concern in the git page:
>
> "This is the same issue as defining a function with 'auto' in one place and referring to it having a specific type/attribute in another. So I think all the same arguments and reasoning discussed above apply equally."

Initially I thought you were replying to something further up in the thread as it seemed more applicable to something I read before, and I did feel the issue of inheritance was different. But I think you are correct, it is the same issue.

On Wednesday, 17 April 2013 at 08:39:37 UTC, qznc wrote:
> An alternative approach would be to do this optimization during optimization. However, this means it has to be reimplemented in dmd, LLVM, GCC separately. This is e.g. the case for pure-inference in C code.

LDC/LLVM does something very similar already (on the IR level), but obviously not across multiple compilation units, as the function body has to be available to the optimizer.

David

 Th
On 04/17/2013 09:06 PM, Walter Bright wrote:
> On 4/17/2013 10:41 AM, Jesse Phillips wrote:
>> I wish to bring Someboddies consern to this form.
>>
>> What does attribute inference mean for inheritance?
>
>
> I specifically addressed his concern in the git page:
>
> "This is the same issue as defining a function with 'auto' in one place
> and referring to it having a specific type/attribute in another. So I
> think all the same arguments and reasoning discussed above apply equally."
>

Why is this a valid form of reasoning? The signature of a function that has its return type inferred includes the function body.

Furthermore, it is not the same issue. It is the dual issue. The distinction is very relevant because pure and nothrow are designed in an asymmetric way, given inference. Attributes can force the specification in one direction only (provide more guarantees to callers), but not in the other one (require less from subclasses).

The concerns the latter can certainly not be dismissed by using the same arguments and reasoning as for the former without any further examination.

On 4/17/2013 3:20 PM, Timon Gehr wrote:
>> "This is the same issue as defining a function with 'auto' in one place
>> and referring to it having a specific type/attribute in another. So I
>> think all the same arguments and reasoning discussed above apply equally."
>>
>
> Why is this a valid form of reasoning? The signature of a function that has its
> return type inferred includes the function body.
>
> Furthermore, it is not the same issue. It is the dual issue. The distinction is
> very relevant because pure and nothrow are designed in an asymmetric way,

They are the same - adding the attribute retains covariance.

> given
> inference. Attributes can force the specification in one direction only (provide
> more guarantees to callers), but not in the other one (require less from
> subclasses).

Pure and nothrow provide more guarantees, hence covariance.

> The concerns the latter can certainly not be dismissed by using the same
> arguments and reasoning as for the former without any further examination.

They're both the same issue of covariance.

On Wednesday, 17 April 2013 at 19:53:07 UTC, Walter Bright wrote:
> On 4/17/2013 12:58 AM, deadalnix wrote:
>> Back to the subject, if auto bind to the function it must infers attributes, if
>> it binds to the return type, it mustn't. And right now, storage class bind to
>> the function.
>
> 'auto', like all storage class annotations such as 'const', binds to the declaration and the declaration's type. It is perfectly consistent.
>
>
> > extern(C) void function() foo; // does extern binds to foo,
> foo's type or both ?
>
> foo is being declared, so it binds to foo.
>
> > pure function() function() bar; // is bar a pure function ?
> is bar() pure ? Noth ? How to choose ?
>
> bar is being declared, so it binds to bar.

Yes I know. That was my point : auto bind to the function according to current spec, so function type should be inferred, which imply both return type and attributes.

Points raised in the thread show that people need in general to be able to annotate specifically the return type or whatever, and this is rather difficult with the current state of thing (and also it seems quite hard to fix).

On Wednesday, 17 April 2013 at 23:46:08 UTC, Walter Bright wrote:
> On 4/17/2013 3:20 PM, Timon Gehr wrote:
>>> "This is the same issue as defining a function with 'auto' in one place
>>> and referring to it having a specific type/attribute in another. So I
>>> think all the same arguments and reasoning discussed above apply equally."
>>>
>>
>> Why is this a valid form of reasoning? The signature of a function that has its
>> return type inferred includes the function body.
>>
>> Furthermore, it is not the same issue. It is the dual issue. The distinction is
>> very relevant because pure and nothrow are designed in an asymmetric way,
>
> They are the same - adding the attribute retains covariance.
>

No : if a super function suddenly become pure because its implementation changed, then all kind of subclasses can broke. Generally, it is a bad idea for a super class to be aware of its subclasses.

But defining a function that is going to be overridden as auto is asking for trouble in the first place.

On 4/17/2013 6:28 PM, deadalnix wrote:
> Points raised in the thread show that people need in general to be able to
> annotate specifically the return type or whatever, and this is rather difficult
> with the current state of thing (and also it seems quite hard to fix).

To annotate the return type specifically with, say, const:

    const(T) foo();

And in fact const with parens works as a general type constructor:

    const(T)* foo();  // return mutable pointer to const T

const without parens applies to the declaration.

On 4/17/2013 6:32 PM, deadalnix wrote:
> No : if a super function suddenly become pure because its implementation
> changed, then all kind of subclasses can broke. Generally, it is a bad idea for
> a super class to be aware of its subclasses.

Yet this is the same issue as auto for other functions.


> But defining a function that is going to be overridden as auto is asking for
> trouble in the first place.

Of course.

On Thursday, 18 April 2013 at 01:52:10 UTC, Walter Bright wrote:
> To annotate the return type specifically with, say, const:
>
>     const(T) foo();
>
> And in fact const with parens works as a general type constructor:
>
>     const(T)* foo();  // return mutable pointer to const T
>
> const without parens applies to the declaration.

This doesn't work with many attributes.

On 4/16/2013 8:22 AM, 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

What do you think of this:

     typeof(return) foo(int x) { return x; }

? That would only infer the return type, not the attributes.