www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Auto keyword and when to use it

reply QueenSvetlana <svetlanalilyrosemond gmail.com> writes:
I'm new to D programming, but have I have a background with 
Python.

I'm struggling to understand what the auto keyword is for and 
it's appropriate uses. From research, it seems to share the same 

it states:

https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/var

... variables that are declared at method scope can have an 
implicit "type" var. An implicitly typed local variable is 
strongly typed just as if you had declared the type yourself, but 
the compiler determines the type.

Is the same true for auto? For example, if I have a class Person, 
I might have attributes such as FirstName, LastName which should 
obviously be strings but will D allow me to declare class level 
attributes with auto?
Aug 20 2018
next sibling parent reply JN <666total wp.pl> writes:
On Monday, 20 August 2018 at 17:24:19 UTC, QueenSvetlana wrote:

 I'm new to D programming, but have I have a background with 
 Python.

 I'm struggling to understand what the auto keyword is for and 
 it's appropriate uses. From research, it seems to share the 

 documentation, it states:

 https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/var

 ... variables that are declared at method scope can have an 
 implicit "type" var. An implicitly typed local variable is 
 strongly typed just as if you had declared the type yourself, 
 but the compiler determines the type.

 Is the same true for auto? For example, if I have a class 
 Person, I might have attributes such as FirstName, LastName 
 which should obviously be strings but will D allow me to 
 declare class level attributes with auto?






auto x = "hi";

will make x a string.

But if you later try:

x = 5;

it will throw an error, because x is a string. It's used to save 
you the typing of the type, it doesn't make the language 
dynamically typed.
Aug 20 2018
parent reply QueenSvetlana <svetlanalilyrosemond gmail.com> writes:
Great!

So I can't declare class level variables with auto, correct? only 
local method variables?
Aug 20 2018
next sibling parent Colin <grogan.colin gmail.com> writes:
On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:

 Great!

 So I can't declare class level variables with auto, correct? 
 only local method variables?


You can use auto if you're setting the class level variable to a 
default.

class X {
   auto i = 42; // i will be an int

}
Aug 20 2018
prev sibling next sibling parent reply JN <666total wp.pl> writes:
On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:

 Great!

 So I can't declare class level variables with auto, correct? 
 only local method variables?


You can, globals, class members:

class Foo
{
     auto bar = "hi";
}

Foo.bar will be of string type here, because "hi" is a string. 
What you can't do is:

class Foo
{
     auto bar;
}

because now the compiler doesn't know what type 'bar' is supposed 
to be.
Aug 20 2018
parent reply QueenSvetlana <svetlanalilyrosemond gmail.com> writes:
On Monday, 20 August 2018 at 17:55:11 UTC, JN wrote:

 class Foo
 {
     auto bar;
 }

 because now the compiler doesn't know what type 'bar' is 
 supposed to be.


Just to clarify, even if I set bar in the constructor, I can't 
declare it with auto first, correct? I would have to declare a 
specific type?
Aug 21 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, August 21, 2018 12:22:42 PM MDT QueenSvetlana via Digitalmars-d-
learn wrote:

 On Monday, 20 August 2018 at 17:55:11 UTC, JN wrote:

 class Foo
 {

     auto bar;

 }

 because now the compiler doesn't know what type 'bar' is
 supposed to be.


 Just to clarify, even if I set bar in the constructor, I can't
 declare it with auto first, correct? I would have to declare a
 specific type?


Yes. As Mike's excellent response explained, auto is simply used to indicate
that you're not providing the explicit type and that it should be inferred
from the direct initialization of the variable. Whenever an explicit type is
not provided for a variable when declaring it, you _must_ use direct
initialization so that the type can be inferred. You can't do something like
have the type of a member variable inferred from what the constructor is
doing. And code like

auto foo;

is never legal.

- Jonathan M Davis
Aug 21 2018
prev sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Monday, 20 August 2018 at 17:52:17 UTC, QueenSvetlana wrote:

 So I can't declare class level variables with auto, correct? 
 only local method variables?



that the latter languages allow automatically typed declarations 
only for local (method/function-scope) variables, and forbid them 
for class or struct member variables (aka fields); whereas D 
allows auto anywhere (even function/method return type! -- which 

methods/lambdas).

I'm in favor of the AAA ("Auto" Almost Always) paradigm, but as 
long as the type if obvious to a human reader. I don't favor them 
for numeric types for this reason (non obvious bitsize, 
signedness...) It's up to each programmer. Only if someone likes 
"Type x = new Type()" instead of "auto x = new Type()" I would 
say they're clearly wrong.
Aug 21 2018
parent reply QueenSvetlana <svetlanalilyrosemond gmail.com> writes:
On Tuesday, 21 August 2018 at 16:15:32 UTC, XavierAP wrote:

Only if someone
 likes "Type x = new Type()" instead of "auto x = new Type()" I 
 would say they're clearly wrong.


As you stated it's up to the programmer to decided. I'm in favor 
of Type x = new Type() because when it comes to constructing a 
class it usually means more code to verify the types, for example:


class Person {
   auto firstName;
   auto lastName;

   // constuctor to set first and last names

}

The compiler doesn't know know what firstName or lastName is 
supposed to be and a programmer might make the obvious assumption 
and use them as strings.

Doing this also means you have reject any type that isn't a 
string which means a private function to check the type that was 
pass to the constructor before initializing it. Where as if you 
declared it as a string to start of with, all you have to ensure 
is that it's not blank or contain illegal characters.

As the answer stated above doing what I showed in my example 
isn't allowed and this is where Python gets frustrating, because 
at any point the types could change. They introduced type hints, 
but it's not enforced, it just makes it more readable, you still 
have to write code to ensure the proper types were passed.
Aug 21 2018
parent reply Jim Balter <Jim Balter.name> writes:
On Tuesday, 21 August 2018 at 18:18:25 UTC, QueenSvetlana wrote:

 On Tuesday, 21 August 2018 at 16:15:32 UTC, XavierAP wrote:

Only if someone
 likes "Type x = new Type()" instead of "auto x = new Type()" I 
 would say they're clearly wrong.


 As you stated it's up to the programmer to decided. I'm in 
 favor of Type x = new Type()


There is nothing to recommend such redundancy; don't do it.


 because when it comes to constructing a class it usually means 
 more code to verify the types


Type inference doesn't require more code.


 for example:


Your example has no bearing on any of the above ... it's not an 
example of it.


 class Person {
   auto firstName;
   auto lastName;

   // constuctor to set first and last names

 }


That code is meaningless and isn't legal. You need to either 
provide explicit types, or they need to be inferable from the 
type of the initializer.


 The compiler doesn't know know what firstName or lastName is 
 supposed to be and a programmer might make the obvious 
 assumption and use them as strings.


The programmer can't make any assumption because the code is not 
remotely legal.


 Doing this also means you have reject any type that isn't a 
 string which means a private function to check the type that 
 was pass to the constructor before initializing it. Where as if 
 you declared it as a string to start of with, all you have to 
 ensure is that it's not blank or contain illegal characters.


This is all incoherent. D is a statically typed language.


 As the answer stated above doing what I showed in my example 
 isn't allowed and this is where Python gets frustrating, 
 because at any point the types could change. They introduced 
 type hints, but it's not enforced, it just makes it more 
 readable, you still have to write code to ensure the proper 
 types were passed.


Python is not statically typed; D is. Why are you talking about 


allowed for non-local declarations.
Aug 21 2018
parent reply QueenSvetlana <svetlanalilyrosemond gmail.com> writes:
On Tuesday, 21 August 2018 at 18:44:15 UTC, Jim Balter wrote:

 Python is not statically typed; D is. Why are you talking about 


 allowed for non-local declarations.


I think you misunderstood my point. Let me elaborate. In Python a 
type could change at anytime, for example:

number = 1

In Python the variable number will be treated as an int, but at 
any point in my code, that could change, in Python this is legal:

number = "one"

The code will compile and run. Now Python introduced type hints 
to tell the reader how to treat the variable.

The problem with the code is, when you have a class, take my 
Person example, a person will obviously have a first and last 
name, which should be strings, now without validation I can pass 
ints to those variables, which is undesirable. I would need a 
private function to check the types passed and reject it if they 
aren't strings, in addition to if the string is blank or contains 
foreign characters.

I had a misunderstanding about the keyword auto because I 
wrongfully believed that it made the code like Python, and for 
that I apologize. I thought you were allowed to make class 
variables auto, so for example:

class Person{

     auto firstName
     auto lastName
}

If this was allowed, when I create my person object, I can pass 
ints to firstName and lastName, which is obviously undesirable. I 
would need to check what value types were passed and reject them 
if they aren't strings.

As pointed out in the answers above, this isn't legal, which 
means, there is no need to check anything, it won't compile.
Aug 21 2018
parent XavierAP <n3minis-git yahoo.es> writes:
On Tuesday, 21 August 2018 at 21:37:00 UTC, QueenSvetlana wrote:

 I had a misunderstanding about the keyword auto because I 
 wrongfully believed that it made the code like Python


Exactly, you are thinking still like D is Python or also 
dynamically typed. :) You will get when compiling errors that 
Python wouldn't detect until run-time (or with your private 
methods).

- A declaration with auto needs to include an initialization.
- The code will be equivalent as if replacing "auto" with the 
inferred type. It is not left for later to check.

I'm not terribly bothered btw by "Type = new Type()" but often 
type names get too long or include namespaces... 
"mylib.numeric.squareObjectWithPointyCorners = new 
mylib.numeric.squareObjectWithPointyCorners()"
Aug 22 2018
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 20 August 2018 at 17:24:19 UTC, QueenSvetlana wrote:

 I'm struggling to understand what the auto keyword is for and 
 it's appropriate uses. From research, it seems to share the 



auto is one of the most misunderstood understood features in D. 
By that I mean, everyone understands the effect of auto, but 
aren't always accurate in describing it.

In D, every variable must have a storage class. The automatic 
storage class is the default and is never specified in the 
declaration:

int x = 10;

Other storage classes are const, immutable, and shared. These are 
also type constructors, so they become part of the type:

const int y = 11;      // type is const(int)
immutable int z = 12;  // type is immutable(int)
shared int s = 13;     // type is shared(int)

D allows the type to be dropped in declarations that include an 
initializer. In those cases, the type will be inferred:

const y = 11;      // type is const(int)
immutable z = 12;  // type is immutable(int)
shared s = 13;     // type is shared(int)

You can also drop the type in declarations with automatic 
storage, but `x = 10;` is not allowed as a variable declaration. 
You must include at minimum a type or a storage class. That's 
where auto comes in:

auto x = 10;  // type is int

So that's all it is. It's nothing special. It just means you're 
declaring a variable with the default storage class and want the 
compiler to infer the type.

So the question 'when should I use auto' is probably the wrong 
way to look at it. 'When should I use type inference' is a better 
way to frame it. And the answer to that is that there is no right 
answer.

I tend to use type inference liberally, almost always with 
const/immutbale locals, though I tend to use auto only when the 
type name is longer than four characters. For me, it's a nice way 
to save keystrokes. Some take a dim view of that approach and 
prefer to use it only when they actually require type inference. 
I mostly program alone, though, and I have a number of habits 
others may label 'bad', so I'm happy with my approach.
Aug 20 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/20/18 9:15 PM, Mike Parker wrote:

 I tend to use type inference liberally, almost always with 
 const/immutbale locals, though I tend to use auto only when the type 
 name is longer than four characters. For me, it's a nice way to save 
 keystrokes. Some take a dim view of that approach and prefer to use it 
 only when they actually require type inference. I mostly program alone, 
 though, and I have a number of habits others may label 'bad', so I'm 
 happy with my approach.


I'm more extreme in this camp -- I use auto everywhere. Why? because at 
some point, I may change some type somewhere (oops, I should have wrote 
size_t instead of uint), and then I would have to go through and change 
all the places I put the concrete type if I hadn't used auto.

While using functions, I also can use auto and not have to worry about 
the type. I know kind of what it is (integer type, string type, range 
type, etc), and not care what the exact type is.

-Steve
Aug 21 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, August 21, 2018 9:04:31 AM MDT Steven Schveighoffer via 
Digitalmars-d-learn wrote:

 On 8/20/18 9:15 PM, Mike Parker wrote:

 I tend to use type inference liberally, almost always with
 const/immutbale locals, though I tend to use auto only when the type
 name is longer than four characters. For me, it's a nice way to save
 keystrokes. Some take a dim view of that approach and prefer to use it
 only when they actually require type inference. I mostly program alone,
 though, and I have a number of habits others may label 'bad', so I'm
 happy with my approach.


 I'm more extreme in this camp -- I use auto everywhere. Why? because at
 some point, I may change some type somewhere (oops, I should have wrote
 size_t instead of uint), and then I would have to go through and change
 all the places I put the concrete type if I hadn't used auto.

 While using functions, I also can use auto and not have to worry about
 the type. I know kind of what it is (integer type, string type, range
 type, etc), and not care what the exact type is.


I'd argue that it's generally better to use explicit types where possible in
function signatures so that the documentation is clearer, but overall, I
agree with you, and if I can use type inference, I almost always do.
However, it does seem like the sort of thing that many newcomers to D balk
at initially, whereas most of us who have been using it for a while have no
problem with it and prefer it.

- Jonathan M Davis
Aug 21 2018