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.

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

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

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.

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()"