"Lars T. Kyllingstad" , dans le message (digitalmars.D:170381), a
> That said, I was still wrong. :)  I just tried it now, and apparently you can write pointless stuff like "auto extern int foo;" and DMD will compile it just fine.  (And, unless that is a bug, it means D has redefined 'auto' to mean absolutely nothing, except to be a marker saying "this is a declaration", allowing one to omit both storage class and type.)

dlang.org states:

| Auto Attribute
| The auto attribute is used when there are no other attributes and type
| inference is desired.

So indeed, in a variable declaration, auto has no meaning other than saying "this is a declaration".

-- 
Christophe

On Thursday, 21 June 2012 at 09:14:42 UTC, Lars T. Kyllingstad wrote:
> auto should probably be removed from the list of storage classes in the D spec, then.

Or better, since the definition of StorageClass at http://dlang.org/declaration.html includes a bunch of things that aren't really storage classes, find a better name than StorageClass...

-Lars

2012/6/21 Mehrdad <wfunction@hotmail.com>:
> On Thursday, 21 June 2012 at 05:54:32 UTC, Lars T. Kyllingstad wrote:
>>
>> No. Many don't realise this, but "auto" doesn't  actually stand for "automatic type inference". It is a storage class
>>
>> Lars
>
>
>
> auto int a = 5;
> // Error: variable a storage class 'auto' has no effect if type is not
> inferred, did you mean 'scope'?
>
>
>
> I don't understand what kind of a "storage class" this is.
>
> You would be correct in C, but is it really a 'storage class' in D?
>
> (Sure it's called that, but it doesn't seem to behave like one...)

The word 'storage class' seems to me that comes from C language, but I think it is almost incorrect word in current D.

Different from C, it can qualify almost of D declarations - variable, function, template, and class/struct declarations.

I think that to invent new/better word for that element of the language is important work of the community.

Kenji Hara

On Thursday, June 21, 2012 11:14:40 Lars T. Kyllingstad wrote:
> That said, I was still wrong. :)  I just tried it now, and apparently you can write pointless stuff like "auto extern int foo;" and DMD will compile it just fine.  (And, unless that is a bug, it means D has redefined 'auto' to mean absolutely nothing, except to be a marker saying "this is a declaration", allowing one to omit both storage class and type.)

I believe that auto has been redefined in C++11 as well. In both, all it really means is that the type is inferred.

> auto should probably be removed from the list of storage classes in the D spec, then.

The spec isn't _at all_ clear on what on earth a storage class is in D. I tried to get clarification on that not too long ago and failed.

http://stackoverflow.com/questions/10150510/what-are-the-storage-classes-in-d http://www.digitalmars.com/d/archives/digitalmars/D/Definitive_list_of_storage_classes_164063.html http://forum.dlang.org/post/jmipot$d42$1@digitalmars.com

It seems like it's any attribute which can go on a variable declaration save for type qualifiers. So, it's pretty much meaningless.

> > _All_ variables
> > cease to exist when they exit scope.
> 
> Not static ones, but again maybe you took "stop existing" to refer to the name rather than the storage.

No, you're right. I forgot about static.

- Jonathan M Davis

On Thursday, 21 June 2012 at 10:01:18 UTC, Jonathan M Davis wrote:
> On Thursday, June 21, 2012 11:14:40 Lars T. Kyllingstad wrote:
>> That said, I was still wrong. :)  I just tried it now, and
>> apparently you can write pointless stuff like "auto extern int
>> foo;" and DMD will compile it just fine.  (And, unless that is a
>> bug, it means D has redefined 'auto' to mean absolutely nothing,
>> except to be a marker saying "this is a declaration", allowing
>> one to omit both storage class and type.)
>
> I believe that auto has been redefined in C++11 as well. In both, all it really
> means is that the type is inferred.

The history of 'auto' in C++ is actually a bit interesting.  Here's a bit from Bjarne Stroustrup's C++11 FAQ (which is an awesome resource, btw):

"The auto feature has the distinction to be the earliest to be suggested and implemented: I had it working in my Cfront implementation in early 1984, but was forced to take it out because of C compatibility problems. Those compatibility problems disappeared when C++98 and C99 accepted the removal of "implicit int"; that is, both languages require every variable and function to be defined with an explicit type. The old meaning of auto ("this is a local variable") is now illegal. Several committee members trawled through millions of lines of code finding only a handful of uses -- and most of those were in test suites or appeared to be bugs."


>> auto should probably be removed from the list of storage classes
>> in the D spec, then.
>
> The spec isn't _at all_ clear on what on earth a storage class is in D. I
> tried to get clarification on that not too long ago and failed.

At the very least, if we keep using that term, it should have something to do with how stuff is stored. ;)

-Lars

> I believe that auto has been redefined in C++11 as well. In both, all it really
> means is that the type is inferred.

That's what I seemed to remember as well. Originally it had something to do with scope, but it was basically obsolete because that was the default storage class anyway, so nobody was using it.

In the latest iteration of C++ they decided to redefine the keyword to mean automatic type inference. This avoided having to introduce a new keyword (which could break existing code that happened to use that word for a variable name) and it was unlikely to cause problems with old code. Storage class for local variables is still the same default anyway.

(The only possible error could be if someone wrote "auto a = b" as shorthand for "auto int a = b" with b some type other than int, which would have been legal in very old versions of C but extremely unlikely to ever be used since auto does nothing for an int)

> I believe that auto has been redefined in C++11 as well. In both, all it really
> means is that the type is inferred.

That's what I seemed to remember as well. Originally it had
something to do with scope, but it was basically obsolete because
that was the default anyway, so nobody was using it.

In the latest iteration of C++ they decided to redefine the
keyword to mean automatic type inference. This avoided having to
introduce a new keyword (which could break existing code that
happened to use that word for a variable name) and it was
unlikely to cause problems with old code. Storage class for local
variables is still the same default anyway so any code that relied
on variables being old-style "auto" would still work the same.

The only possible error could be if someone wrote "auto a = b"
as shorthand for "auto int a = b" with b some type other than
int, which would have been legal in very old versions of C but
extremely unlikely to ever be used since auto does nothing for an
int. They decided to take that chance :-)

Back in the ancient history of D (y'know, several years ago) there actually was an 'auto' storage class as described here, and it was the default as with C.  It is retained in the current usage so that type inference for undecorated locals would still be available, but indeed no longer serves any other purpose.

Lars is still right in the sense that 'const a = b' really isn't shorthand for 'const auto a = b'.  However, it's largely moot since the original meaning of auto is gone.  Indeed "storage class" in general seems to have gotten out of hand, as a term.  It would be easy enough to clean up by moving the inappropriate members out of that list and into a new yet-to-be-named category. Of course I suppose the compiler's internals would be free to continue seeing them all as one happy family as it now does.

----------

More on topic, the moment I saw the mention of := it immediately read as "Pascal like assignment" to me.  I have no problem with languages that actually treat this as two operators (: type = init) with the digraph as the type inference shorthand, but outside those sort of grammars it just feels "out of place."  The only place this pattern appears in D is in template parameters, and even that has always looked a little funky to me (although not so bad as to be abhorrent).

template Foo ( T : ulong = size_t ) { ... }
// accepts any unsigned integral type, and defaults to the size_t alias

On Wednesday, 20 June 2012 at 14:36:48 UTC, ixid wrote:
> Is there any reason not to add this so you can use foo := bar as a shorthand for auto foo = bar?

If the rest of D's syntax where completely different, then I would agree with you're purposed syntax here. But as it stands, this is completely inconsistent with the rest of D, and for that reason alone shouldn't be introduced. All it can add is confusion.

This is one of the many things I really don't like about Go. Often in Go you'll get syntax like:

  var x int
  y := 30

which just looks like there's completely different things going on between those lines. What would have been much better is to simply remove the 'var' keyword altogether:

  x : int
  y := 10

  // synonymous:
  z := 10u
  z : uint = 10