On Wednesday, 17 April 2013 at 02:22:31 UTC, Walter Bright wrote:
> On 4/16/2013 7:01 PM, deadalnix wrote:
>> 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
>>
>> Oh Yes, Yes, Yes, god Yes !
>> Yes, Yes, Yes !
>>
>> Ho Yes !
>
> Not sure what you're saying yes to - the pro or the con?

Yes to the pull request, yes to the inference. I agree with you, I know it may sound hard to believe, but it had to happen one day :D

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'm not convinced that specifying the exact return type is such a huge inconvenience to those who use separate compilation.

I don't view this as an inconsistency, but definitely a change to why one might choose to use auto.

I'm pretty much for this change. However, I also think it would be good to introduce attributes to specify a throwing function as it would have uses in a file headed with

    nothrow:

I'd suggest the same for pure, but 'nopure' isn't the greatest of names. Anyway it is the same reason we have @system, I'd just hope they don't get added as @throws and @nopure as that would be inconsistent.

On 4/16/2013 7:30 PM, deadalnix wrote:
> I agree with you, I know it may
> sound hard to believe, but it had to happen one day :D

I'll mark it on my calendar!

BTW, I think we can do attribute inference for all private functions, too.

On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
> On 4/16/2013 7:30 PM, deadalnix wrote:
>> I agree with you, I know it may
>> sound hard to believe, but it had to happen one day :D
>
> I'll mark it on my calendar!
>
> BTW, I think we can do attribute inference for all private functions, too.

Don't this risk to conflict with LTO ?

On 4/16/2013 10:31 PM, deadalnix wrote:
> On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
>> BTW, I think we can do attribute inference for all private functions, too.
>
> Don't this risk to conflict with LTO ?

How so?

On Wednesday, 17 April 2013 at 05:55:07 UTC, Walter Bright wrote:
> On 4/16/2013 10:31 PM, deadalnix wrote:
>> On Wednesday, 17 April 2013 at 04:44:59 UTC, Walter Bright wrote:
>>> BTW, I think we can do attribute inference for all private functions, too.
>>
>> Don't this risk to conflict with LTO ?
>
> How so?

Never mind, I think I was wrong. It is a good idea.

On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips wrote:
> On Tuesday, 16 April 2013 at 20:21:00 UTC, 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. Indeed, this is part of the original reason for auto's existence. Denying return type deduction for this use case is a major inconvenience.
>
> How frequently do you write a non-templated function which returns a complex template type? It isn't something I really think about, but I'm pretty sure if I am returning a complex template type I've already got the function a template.

Often enough. I often find myself returning ranges, which are almost invariably complex template types.

And, to be honest, I would just like to use auto without being locked into inferred attributes. It just feels wrong that these things should be conflated, and I get the feeling we will regret this later on when D starts to be used in larger projects.

On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander wrote:
> Often enough. I often find myself returning ranges, which are almost invariably complex template types.
>
> And, to be honest, I would just like to use auto without being locked into inferred attributes. It just feels wrong that these things should be conflated, and I get the feeling we will regret this later on when D starts to be used in larger projects.

Note that this is consistent with many choice D made.

auto is a storage class. storage class usually stick to the function, not the return type :
const Foo bar(); // Error as const qualify bar and not Foo.

auto is about type inference. Attribute is part of the function type as much as it return type, and so it is expected that auto applied to a function infer its attributes and its return type.

The problem you are talking about is very real, but much broader than this auto thing. The problem is that you have no control on what the storage classes bind on.

Examples :
extern(C) void function() foo; // does extern binds to foo, foo's type or both ?
pure function() function() bar; // is bar a pure function ? is bar() pure ? Noth ? How to choose ?

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.

W dniu 16.04.2013 17:22, Andrei Alexandrescu pisze:
> There's a discussion that may be of interest to the larger community:
> https://github.com/D-Programming-Language/dmd/pull/1877

On demand inference FTW!

void fn() auto {
    ...
}

auto fn() auto {
    ...
}

On Wednesday, 17 April 2013 at 07:04:16 UTC, Peter Alexander wrote:
> On Wednesday, 17 April 2013 at 01:55:54 UTC, Jesse Phillips wrote:
>> On Tuesday, 16 April 2013 at 20:21:00 UTC, 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. Indeed, this is part of the original reason for auto's existence. Denying return type deduction for this use case is a major inconvenience.
>>
>> How frequently do you write a non-templated function which returns a complex template type? It isn't something I really think about, but I'm pretty sure if I am returning a complex template type I've already got the function a template.
>
> Often enough. I often find myself returning ranges, which are almost invariably complex template types.
>
> And, to be honest, I would just like to use auto without being locked into inferred attributes. It just feels wrong that these things should be conflated, and I get the feeling we will regret this later on when D starts to be used in larger projects.


I strongly believe you should never use "auto" for API types, because it is too easy to break them. If Dont-Repeat-Yourself/complex types is a problem, they should be solved at the other end by enhancing function body type inference.

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.