On 3/12/23 06:07, DLearner wrote:
> 1. As a shorthand to make the type of the variable being declared the
> same as the type on the right hand side of an initial assignment.
As Adam explained, D already has type inference without a special keyword.
However, some places where 'auto' (or
On Sunday, 12 March 2023 at 13:27:05 UTC, Adam D Ruppe wrote:
[...] *any* storage class will work for type inference. [...]
After heaving read [1] I immediately thought of this:
void main ()
{
deprecated i = 3;
i = 4;
}
$ dmd test.d
test.d(4): Deprecation: variable
On Sunday, 12 March 2023 at 15:31:07 UTC, Salih Dincer wrote:
Moreover, `auto ref` or `ref auto` is needed in functions.
That's because `ref` isn't part of the argument or return value's
type, so it isn't covered by **type** inference. Instead, D has a
totally separate feature for "`ref`
.
The auto keyword is really helpful for shortening it. But in at
least 2 cases (one of which is interfaces) it should help the
compiler. For example, contrary to expected, it is dynamic array:
```d
auto arr = [ 1, 2, 3 ];
```
Moreover, `auto ref` or `ref auto` is needed in functions.
SDB@79
On Sunday, 12 March 2023 at 13:07:58 UTC, DLearner wrote:
Is it correct that this _single_ keyword is used to indicate
_two_ quite different things:
No, it only actually does #2 in your thing. The type is optional
meaning *any* storage class will work for type inference. `auto`
is not
Is it correct that this _single_ keyword is used to indicate
_two_ quite different things:
1. As a shorthand to make the type of the variable being declared
the same as the type on the right hand side of an initial
assignment.
Example: ```auto A = 5;``` makes A an int.
2. To indicate
On Thu, Jan 30, 2020 at 09:37:40AM +, Michael via Digitalmars-d-learn wrote:
[...]
> auto elements = buf.to!string.strip.split(" ").filter!(a => a != "");
>
> That line strips white space from buf, splits it, removes empty
> elements and returns an array of strings. At least I thought so.
If
On Thursday, January 30, 2020 2:37:40 AM MST Michael via Digitalmars-d-learn
wrote:
> auto is surely a nice feature. Nonetheless I'd prefer to use
> explicit types. So when reading a code and I see the auto keyword
> I also have to find out what kind of type is meant.
>
> I have
auto is surely a nice feature. Nonetheless I'd prefer to use
explicit types. So when reading a code and I see the auto keyword
I also have to find out what kind of type is meant.
I have a line of code that looks like this:
auto elements = buf.to!string.strip.split(" &quo
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
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
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
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
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
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
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
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
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
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
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
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
}
Great!
So I can't declare class level variables with auto, correct? only
local method variables?
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
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
On Wednesday, 24 July 2013 at 11:26:32 UTC, Mike Parker wrote:
This is the exact behavior I would expect. I think of auto as
this variable is going to be the same type as that variable.
Since in is const int, then j also is going to be const int. If
you want to copy n into a nonconst variable,
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most people
wouldn't want new variables inheriting const.
Alex H:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people wouldn't want new variables inheriting const.
It's a bit annoying. I don't remember people discussing
On Wednesday, 24 July 2013 at 08:07:55 UTC, Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people
wouldn't want new variables inheriting
Am 24.07.2013 11:39, schrieb bearophile:
Alex H:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people wouldn't want new variables inheriting const.
It's a bit
dennis luehring:
and how would it look to preserve the const if auto would
auto-rip it of?
You could write:
immutable j = n;
For every default behavour you need a way to implement the other
nicely :-)
Currently for the problem of the OP you can use this:
Unqual!(typeof(n)) j = n;
Bye,
On Wednesday, 24 July 2013 at 10:01:14 UTC, bearophile wrote:
dennis luehring:
and how would it look to preserve the const if auto would
auto-rip it of?
You could write:
immutable j = n;
For every default behavour you need a way to implement the
other nicely :-)
Currently for the
On 07/24/13 12:09, monarch_dodra wrote:
Keeping it to same type, 100% of the time seems like the best.
No, it's a design bug. The head qualifier(s) should always be stripped
when copying objects. Stripping is always fine (ie safe), not doing it
just creates other problems, like the one in OP, or
On Wednesday, 24 July 2013 at 10:37:40 UTC, Artur Skawina wrote:
On 07/24/13 12:09, monarch_dodra wrote:
Keeping it to same type, 100% of the time seems like the
best.
No, it's a design bug. The head qualifier(s) should always be
stripped
when copying objects. Stripping is always fine (ie
On Wednesday, 24 July 2013 at 08:07:55 UTC, Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most
people
wouldn't want new variables inheriting
On Wednesday, July 24, 2013 10:07:54 Alex H wrote:
This code:
void test(const int n)
{
auto j = n;
j++;
}
Gives this error:
cannot modify const expression j
Is this considered a feature or a bug? I would assume most people
wouldn't want new variables inheriting const.
The
On Wednesday, 24 July 2013 at 11:26:32 UTC, Mike Parker wrote:
...
This is the exact behavior I would expect. I think of auto as
this variable is going to be the same type as that variable.
Since in is const int, then j also is going to be const int. If
you want to copy n into a nonconst
I've seen a lot of code lately that uses the auto keyword when
declaring variables, but for some reason I don't really care much
for it.
I'd like to make tutorials for a library I am working on, but I
want to use D style. Does such a style exist? Is auto generally
preferred when declaring
On Thursday, 4 July 2013 at 20:00:18 UTC, Jeremy DeHaan wrote:
I've seen a lot of code lately that uses the auto keyword when
declaring variables, but for some reason I don't really care
much for it.
I'd like to make tutorials for a library I am working on, but I
want to use D style. Does
On Thursday, July 04, 2013 21:54:22 Jeremy DeHaan wrote:
I've seen a lot of code lately that uses the auto keyword when
declaring variables, but for some reason I don't really care much
for it.
I'd like to make tutorials for a library I am working on, but I
want to use D style. Does
39 matches
Mail list logo
