On 4/17/13 4:31 AM, Piotr Szturmaj wrote:
> 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 {
> ...
> }
>

I think this is a bit much. Simplicity is a good commodity to allow oneself of, and absorbing two different meanings of 'auto' in the same construct is not simple.

Andrei

On 4/17/13 3:58 AM, deadalnix wrote:
> 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.

I think this is a solid argument. You may want to paste it in the github discussion for reference.

Andrei

On 4/17/13 8:09 AM, Andrej Mitrovic wrote:
> 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.

It's not supposed to; voldemort functions are by definition non-modular.

Andrei

On Wednesday, 17 April 2013 at 13:59:05 UTC, Peter Alexander wrote:
[...]
>
> 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.

I think you've made some good clarification points.

auto is used only when there is no other storage class, and "storage class" is a somewhat misleading term because some storage class's seem to have nothing to do with "storage".

The point you made, is that what is being proposed is if or if not D should be extended to perform attribute inference along with type inference. The auto keyword is only required when no other storage class is specified, so it really means that attribute inference will be done all the time unless you specifically specify the attributes.

Is this the case?

--rt

On Wednesday, 17 April 2013 at 12:22:21 UTC, Peter Alexander wrote:
> 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.
>

auto is generally understood as type inference, so ti isn't an heresy.

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

It is, because you can't express both "I want return type inference" and " want full type inference"

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

It is sufficient. It is true that it isn't required as absence of type + one storage class means type inference. I kind of oversimplyfied that part.

The intent of auto is still type inference, as this is a storage class that mean nothing, except that it allow to omit the type.

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

What storage class stand for is already a blurry topic. I don't think any confusion can be added.

On Wednesday, 17 April 2013 at 16:10:02 UTC, deadalnix wrote:
> On Wednesday, 17 April 2013 at 12:22:21 UTC, Peter Alexander wrote:
>> 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.
>>
>
> auto is generally understood as type inference, so ti isn't an heresy.
>
>>> 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.
>>
>
> It is, because you can't express both "I want return type inference" and " want full type inference"
>
>>> 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.
>>
>
> It is sufficient. It is true that it isn't required as absence of type + one storage class means type inference. I kind of oversimplyfied that part.
>
> The intent of auto is still type inference, as this is a storage class that mean nothing, except that it allow to omit the type.
>
>> 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.
>
> What storage class stand for is already a blurry topic. I don't think any confusion can be added.

It's certainly not helpful if we keep on blurring the concepts.

The "auto" keyword currently means nothing except that when no other storage class is present you can specify it to allow the compiler to proceed without error, otherwise type inference is always performed unless inference is overridden with an explicit type.

The proposal therefore seems to be about extending D to always perform attribute inference along with type inference unless the attributes are explicitly specified.

The question I have is if the proposal wants to extend the meaning of the "auto' keyword so that it will be required in order for attribute inference to take place, but that indeed does confuse things because we're using the same keyword for two completely two different purposes, and it clashes with the use of auto in some cases.

-rt

On Wednesday, 17 April 2013 at 16:26:30 UTC, Rob T wrote:
> The proposal therefore seems to be about extending D to always perform attribute inference along with type inference unless the attributes are explicitly specified.
>
> The question I have is if the proposal wants to extend the meaning of the "auto' keyword so that it will be required in order for attribute inference to take place, but that indeed does confuse things because we're using the same keyword for two completely two different purposes, and it clashes with the use of auto in some cases.
>
> -rt

This is a very good description of the change.

I don't think auto should be made specific to attribute inference. So I think the discussion should consider:

const foo()//...

would that be something that should also be a attribute inference. I think I'm still ok with that as it is still requesting inference. Note that you can not specify an inferred const return type. That is this makes a the function const (not valid as a free form function), and not the return type.

On 2013-04-16 15:22:56 +0000, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> There's a discussion that may be of interest to the larger community: https://github.com/D-Programming-Language/dmd/pull/1877

I agree attribute inference is needed. I don't think 'auto' is a suitable trigger. It'll encourage people to replace the return type on existing and new functions (making things more obscure) as a way get attribute inference.

Instead, all functions should have the benefit of attribute inference. I'd rather have a marker to prevent it when needed than have to opt it. For instance, if providing a stable API for a library is a concern, put that marker on those exported functions. Perhaps "export" could be that marker.

Unfortunately, that'll be slow. DMD will have to reprocess the function body for every called function transitively each time it compiles. The solution for that is to use .di files as a cache: in the process of creating a .di file the inferred attributes could be made explicit. Then disallow attribute inference for functions parsed from a .di file (so you can still provide a body for inlining). All this might pose a tricky cache-invalidation problem however: when a function somewhere changes you need to purge all the dependent di files *before* recompiling anything. :-/

Compilation speed is not a problem for functions with the "auto" return type because there are only a few of them. At least that's how it is right now. Allowing attribute inference only for this category of function might change those statistics after a few months in the wild, and then you'll have the compilation performance problems described above. Which might not be a bad thing, as then you'll need to overhaul the compilation model to fix this, and then you'll be able to enable it for all functions. ;-)

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

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 wish to bring Someboddies consern to this form.

What does attribute inference mean for inheritance?

Do all derived classes need to be known for inference to take place? Not having the ability to claim a base function can be overridden with a throwing function could cause some issue...

Hmm but we can still specify the type so I guess it still isn't a major, but I could see auto being used more causing a library writer to make restrictions on their function because what they write is applicable but not really considering derived classes could reasonably throw.

17-Apr-2013 01:13, Timon Gehr пишет:
> On 04/16/2013 07:06 PM, Dmitry Olshansky wrote:
>> 16-Apr-2013 19:22, Andrei Alexandrescu пишет:
>>> There's a discussion that may be of interest to the larger community:
>>> https://github.com/D-Programming-Language/dmd/pull/1877
>>>
>>> Andrei
>>
>> In the same vane - how about attribute inference for "ordinary"
>> functions?
>>
>> I recall that just a month ago I had an interesting case - a normal
>> function inside of a templated struct. The thing is that depending on
>> some parameters (of struct) it could be safe or not. But it's not a
>> template itself and its return type is always bool.
>>
>> In the end I just added an empty CT parameter set making it a template.
>> ...
>
> This should not be an issue any more.
>
> http://d.puremagic.com/issues/show_bug.cgi?id=7511
>
>

So it was a bug after all. Good to see it fixed.

-- 
Dmitry Olshansky