On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
> 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.

Very nice !

On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
> 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.

I don't actually have an opinion on whether attributes should be inferred, but '@auto' (as opposed to '@infer') would be a relatively innocuous way to do it explicitly instead of implicitly.

On 4/17/2013 7:50 PM, Zach the Mystic wrote:
> On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
>> 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.
>
> I don't actually have an opinion on whether attributes should be inferred, but
> '@auto' (as opposed to '@infer') would be a relatively innocuous way to do it
> explicitly instead of implicitly.

Except that we already support typeof(return) inside of a function.

W dniu 18.04.2013 04:50, Zach the Mystic pisze:
> On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
>> 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.
>
> I don't actually have an opinion on whether attributes should be
> inferred, but '@auto' (as opposed to '@infer') would be a relatively
> innocuous way to do it explicitly instead of implicitly.

And this can apply to whole scopes.

On 2013-04-17 19:05:01 +0000, Walter Bright <newshound2@digitalmars.com> said:

> On 4/17/2013 10:37 AM, Michel Fortin wrote:
>> Compilation speed is not a problem for functions with the "auto" return type
>> because there are only a few of them.
> 
> It is not a problem right now because the compiler has to semantically analyze their function bodies already in order to determine the return type. It is insignificant to additionally gather the attribute information.

True, but beside the point.

My point was that if auto allows attribute inference people will be tempted to (and will do) change their return types to auto in their programs just to get that benefit (no one wants to annotate all their functions).

Thus, as more and more functions become "auto" compile times will become slower.

Pushed to the extreme, you'd get the same result as if you were inferring attributes for all functions, plus more confusion because all the return types are obfuscated.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca/

On Thursday, 18 April 2013 at 03:19:38 UTC, Walter Bright wrote:
> On 4/17/2013 7:50 PM, Zach the Mystic wrote:
>> On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
>>> 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.
>>
>> I don't actually have an opinion on whether attributes should be inferred, but
>> '@auto' (as opposed to '@infer') would be a relatively innocuous way to do it
>> explicitly instead of implicitly.
>
> Except that we already support typeof(return) inside of a function.

Yeah, I basically agree. If I had to choose right now, typeof(return) makes more sense. It relies on the assumption that most of the time when you want to 'auto' the return type, you also are okay with autoing the attributes (hence typeof(return) will be much rarer than 'auto'). It seems like a pretty safe assumption to make. And it's weird but '@' is just uglier than things without '@', despite that it would be nice for UDAs and other attributes if that weren't the case.

On Thursday, 18 April 2013 at 03:42:50 UTC, Piotr Szturmaj wrote:
> W dniu 18.04.2013 04:50, Zach the Mystic pisze:
>> On Thursday, 18 April 2013 at 02:40:42 UTC, Walter Bright wrote:
>>> 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.
>>
>> I don't actually have an opinion on whether attributes should be
>> inferred, but '@auto' (as opposed to '@infer') would be a relatively
>> innocuous way to do it explicitly instead of implicitly.
>
> And this can apply to whole scopes.

Yeah, that's true... 'typeof(return):' would not look good at the top of a file. I feel like this feature is attempting to turn on a vacuum, seeing how many explicit things can be sucked into the implicit vortex. I think the gold medal would be if there were a way to do everything implicitly, but some things may resist being sucked in, and for good reason. The syntax '@auto' seems like a bronze medal solution, so I'd be glad to see it lose to something better.

2013/4/18 Walter Bright <newshound2@digitalmars.com>

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

It will break existing code.

int foo() {
    typeof(return) bar() { return 1; }
    return bar();
}

typeof(return) represents the return type of foo, that is int.

Kenji Hara

On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
> It will break existing code.
>
> int foo() {
>     typeof(return) bar() { return 1; }
>     return bar();
> }
>
> typeof(return) represents the return type of foo, that is int.
>

That is true :( Don't seem fixable.

On 4/17/2013 11:34 PM, deadalnix wrote:
> On Thursday, 18 April 2013 at 05:59:20 UTC, kenji hara wrote:
>> It will break existing code.
>>
>> int foo() {
>>     typeof(return) bar() { return 1; }
>>     return bar();
>> }
>>
>> typeof(return) represents the return type of foo, that is int.
>>
>
> That is true :( Don't seem fixable.

It is fixable if it is special cased, but special cases stink.