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
