On 4/17/13, Jesse Phillips <Jessekphillips+d@gmail.com> wrote:
> How frequently do you write a non-templated function which returns a complex template type?

This can be common if the function is a member function that returns some kind of a range on internal data, for example:

import std.range;
struct S
{
    int[] arr;
    auto range() { return cycle(arr).stride(2); }
}

There's no need to make "range" a template here, but specifying the return type isn't always possible or easy to do.

On Tue, 16 Apr 2013 21:20:59 +0100, Peter Alexander <peter.alexander.au@gmail.com> 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.

Solution:  You use 'auto' and compile the code producing a .di.  With the fix Andrei mentioned the .di has the full and complete function signature, without 'auto', including return type and all deduced attributes etc.  You alter the signature to suit and copy it back to the .d file.

This is how it should be done, IMO, because now you've explicitly defined your library interface so when you accidentally change/break it by modifying the code in the library function body, the compiler will immediately tell you.

It's win-win or so it seems to me.

> It is an unfortunate situation we are in, with D working best with everything inferred and CTFE-able, yet with those things completely at odds with modularity.

I can't see how it can be any other way.  An interface needs to be clearly defined or it's consumer can't use it.  'auto' does not suit that purpose at all, currently, and this doesn't change with this pull.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

On 4/17/13, Regan Heath <regan@netmail.co.nz> wrote:
> Solution:  You use 'auto' and compile the code producing a .di.  With the fix Andrei mentioned the .di has the full and complete function signature, without 'auto', including return type and all deduced attributes etc.

This doesn't work with voldemort types.

On Wednesday, 17 April 2013 at 07:58:42 UTC, deadalnix wrote:
> 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.

I disagree. Attributes are completely separate from return value, and I do not think it is "expected" that auto should infer attributes.


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

Yes, that is a problem, but not related to this change.


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

I think you are confusing separate things here.

First, 'auto' is a storage class that means 'no other storage class'. It does NOT mean type inference. You do not need to use 'auto' to get type inference. You cannot use 'auto' in conjunction with other storage classes to get type inference.

auto foo(); // type inference
const foo(); // type inference
auto const foo(); // illegal, two storage classes

As you can see, auto is neither sufficient, nor required for type inference. The storage class you use has absolutely nothing to do with type inference. Type inference happens if and only if you do not specify a return type. Storage class and type inference are 100% orthogonal.

With that matter cleared up, your argument no longer holds water. It doesn't matter what 'auto' binds to because 'auto' has nothing to do with return type inference, and shouldn't affect attribute inference either.

The name of this thread is quite misleading. The proposal also has nothing to do with auto. The proposal is to infer attributes when the return type is inferred. I think it's worth being clear on that otherwise people will confuse storage classes with type/attribute inference.

On 4/17/13, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> Type inference happens if and only if you do
> not specify a return type.

That's not true, you still need to use auto. This function definition is illegal:

x() { return 1; }

As for being able to use 'const' for type inference it's completely an implementation issue. It's not by design at all. You can even substitute 'auto' for meaningless crap like this in module scope:

static x() { return 1; }

If return type inference is wanted then 'auto' should be required at all times. What's the point in writing obfuscated code like the above?

On 4/17/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> As for being able to use 'const' for type inference it's completely an implementation issue. It's not by design at all.

Actually I'm wrong about this now that I've re-read the spec. You can use another storage class instead of auto (strangely I don't remember this being discussed in TDPL though). However there are too many things in DMD which are "storage classes", when they shouldn't be. E.g. @property.

On 2013-04-17 10:31, Piotr Szturmaj wrote:

> On demand inference FTW!
>
> void fn() auto {
>      ...
> }
>
> auto fn() auto {
>      ...
> }

Double auto, hehe.

-- 
/Jacob Carlborg

On Wednesday, 17 April 2013 at 12:46:53 UTC, Andrej Mitrovic wrote:
> On 4/17/13, Peter Alexander <peter.alexander.au@gmail.com> wrote:
>> Type inference happens if and only if you do
>> not specify a return type.
>
> That's not true, you still need to use auto. This function definition
> is illegal:
>
> x() { return 1; }

You don't need to use auto. Any storage class will do.


> As for being able to use 'const' for type inference it's completely an
> implementation issue. It's not by design at all. You can even
> substitute 'auto' for meaningless crap like this in module scope:
>
> static x() { return 1; }
>
> If return type inference is wanted then 'auto' should be required at
> all times. What's the point in writing obfuscated code like the above?

Because it's required?

This is illegal:

auto const foo();

If you want type inference then you just need to use:

const foo();

And yes, it is by design. The spec is quite clear on this issue. Type inference is signalled by lack of return type -- not the presence of auto. auto is only required when no other storage class is wanted, to make the parser happy. auto is nothing whatsoever to do with type inference.

On Wednesday, 17 April 2013 at 12:49:41 UTC, Andrej Mitrovic
wrote:
> On 4/17/13, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
>> As for being able to use 'const' for type inference it's completely an
>> implementation issue. It's not by design at all.
>
> Actually I'm wrong about this now that I've re-read the spec. You can
> use another storage class instead of auto (strangely I don't remember
> this being discussed in TDPL though). However there are too many
> things in DMD which are "storage classes", when they shouldn't be.
> E.g. @property.

Sorry, just saw this. Ignore previous reply.

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.

Andrei