Re: Auto keyword and when to use it
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()"
Re: Auto keyword and when to use it
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
Python? You asked whether D's auto is like C#'s var ... it is,
but it doesn't have C#'s pointless restriction of not being
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.
Re: Auto keyword and when to use it
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
Re: Auto keyword and when to use it
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
Re: Auto keyword and when to use it
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
Python? You asked whether D's auto is like C#'s var ... it is,
but it doesn't have C#'s pointless restriction of not being
allowed for non-local declarations.
Re: Auto keyword and when to use it
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?
Re: Auto keyword and when to use it
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.
Re: Auto keyword and when to use it
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?
One difference between D's auto and C#'s var or C++'s auto is
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
C# and C++ allow as well but only case of anonymous
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.
Re: Auto keyword and when to use it
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
Re: Auto keyword and when to use it
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 same capabilities as the var keyword in C#. 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.
Re: Auto keyword and when to use it
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.
Re: Auto keyword and when to use it
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
}
Re: Auto keyword and when to use it
Great! So I can't declare class level variables with auto, correct? only local method variables?
Re: Auto keyword and when to use it
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 same capabilities as the var keyword in C#. From the C# 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? C# doesn't allow this. It basically works like C#. 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.
Auto keyword and when to use it
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 capabilities as the var keyword in C#. From the C# 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? C# doesn't allow this.
