www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto*

reply FoxyBrown <Foxy Brown.IPT> writes:
Create an auto pointer, handy in some cases and fits in the 
language as a natural generalization.
Jul 06 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 06, 2017 at 06:10:57PM +0000, FoxyBrown via Digitalmars-d wrote:

 Create an auto pointer, handy in some cases and fits in the language
 as a natural generalization.


What's an auto pointer?


T

-- 
Truth, Sir, is a cow which will give [skeptics] no more milk, and so they are
gone to milk the bull. -- Sam. Johnson
Jul 06 2017
parent reply FoxyBrown <Foxy Brown.IPT> writes:
On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 06:10:57PM +0000, FoxyBrown via 
 Digitalmars-d wrote:

 Create an auto pointer, handy in some cases and fits in the 
 language as a natural generalization.


 What's an auto pointer?


 T


is it not obvious?

auto x = ...

auto* x = ...

auto* is the pointerized version of auto.


e.g.,

int x = ...

int* x = ...

typeof(x) y = ...
typeof(x)* y = ...


obviously the rhs must be congruent with the type.

auto p = &foo;  // a pointer
auto* p = &foo; // a double pointer to foo.

When having the need to require a pointer to a pointer, it avoids 
having to specify the type in a verbose way.

i.e., the second line above is not valid, but to do it we must 
either cast to void** or use typeof and such to get the correct 
type and make a pointer out of it. auto* simplifies all that.
Jul 06 2017
next sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 06, 2017 at 08:24:24PM +0000, FoxyBrown via Digitalmars-d wrote:
[...]

 auto x = ...
 
 auto* x = ...
 
 auto* is the pointerized version of auto.
 
 
 e.g.,
 
 int x = ...
 
 int* x = ...
 
 typeof(x) y = ...
 typeof(x)* y = ...
 
 
 obviously the rhs must be congruent with the type.
 
 auto p = &foo;  // a pointer
 auto* p = &foo; // a double pointer to foo.
 
 When having the need to require a pointer to a pointer, it avoids
 having to specify the type in a verbose way.
 
 i.e., the second line above is not valid, but to do it we must either
 cast to void** or use typeof and such to get the correct type and make
 a pointer out of it. auto* simplifies all that.


Huh?  How is it even remotely valid to cast a single pointer to a double
pointer implicitly?  If foo is a non-pointer object, `auto p = &foo;`
already gives you a pointer.  If foo itself is also a pointer, `auto p =
&foo;` will already give you a double pointer. There is no need to
"specify the type in a verbose way" at all.

You can't get a double pointer out of a single pointer without saving
the single pointer in an addressable variable, e.g.:

	auto p = &foo;	// takes address of foo (single pointer)
	auto pp = &p;	// takes address of p (double pointer)

It's invalid to take the address of an rvalue, because an rvalue has no
location. I.e., `&(&foo)` is illegal because &foo is an rvalue. Before
you can make a double pointer to it, you have to designate some location
where it is to be stored, so that the double pointer can point to that
location.


T

-- 
The two rules of success: 1. Don't tell everything you know. -- YHL
Jul 06 2017
prev sibling next sibling parent =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 07/06/2017 01:24 PM, FoxyBrown wrote:

 On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 06:10:57PM +0000, FoxyBrown via Digitalmars-d
 wrote:

 Create an auto pointer, handy in some cases and fits in the language
 as a natural generalization.


 What's an auto pointer?


 T


 is it not obvious?


It wasn't obvious at all. :) (I even suspected C++'s std::auto_ptr but 
dropped the thought.)


 auto p = &foo;  // a pointer
 auto* p = &foo; // a double pointer to foo.

 When having the need to require a pointer to a pointer, it avoids having
 to specify the type in a verbose way.

 i.e., the second line above is not valid, but to do it we must either
 cast to void** or use typeof and such to get the correct type and make a
 pointer out of it. auto* simplifies all that.


Let's say foo is type Foo...

Staying with that example and assuming that p has type Foo**, what would 
*p provide? We have the object (foo), we have the pointer to pointer 
(p), but where does the pointer itself live? Only the programmer knows 
where that intermediate pointer is. For example:

struct Foo {
}

void main() {
     auto foo = Foo();
     auto x = &foo;    // A local variable here
     auto p = &x;
}

It seems to work cleanly to me. If you have something else in mind 
please show the troubling line with complete code. :)

Ali
Jul 06 2017
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 6 July 2017 at 20:24:24 UTC, FoxyBrown wrote:

 On Thursday, 6 July 2017 at 18:11:13 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 06:10:57PM +0000, FoxyBrown via 
 Digitalmars-d wrote:

 Create an auto pointer, handy in some cases and fits in the 
 language as a natural generalization.


 What's an auto pointer?


 T


 is it not obvious?

 auto x = ...

 auto* x = ...

 auto* is the pointerized version of auto.


 e.g.,

 int x = ...

 int* x = ...

 typeof(x) y = ...
 typeof(x)* y = ...


 obviously the rhs must be congruent with the type.

 auto p = &foo;  // a pointer
 auto* p = &foo; // a double pointer to foo.

 When having the need to require a pointer to a pointer, it 
 avoids having to specify the type in a verbose way.

 i.e., the second line above is not valid, but to do it we must 
 either cast to void** or use typeof and such to get the correct 
 type and make a pointer out of it. auto* simplifies all that.


Just one thing. auto in D is not a type, it's a storage class. It 
inherited that from C. This means auto* doesn't make any sense as 
the * is part of a type. So your expression lack a proper type. 
Type deduction works by using the type of the rhs of the 
expression and applying to it the storage class of the lhs. This 
means that
auto x = ..; works
but also
static x = ..; works
D does not implemented C's register storage class, but if it did 
register x = .. would also work.
When you understand that you will understand why your proposition 
does not make sense.
Jul 06 2017
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:

 Create an auto pointer, handy in some cases and fits in the 
 language as a natural generalization.


It's been suggested before (as well as more powerful 
generalization for slices and associative arrays), but Andrei 
vetoed it so it probably won't be added even if somebody created 
a formal proposal for it.
Jul 06 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 06, 2017 at 09:42:22PM +0000, Meta via Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:

 Create an auto pointer, handy in some cases and fits in the language
 as a natural generalization.


 
 It's been suggested before (as well as more powerful generalization
 for slices and associative arrays), but Andrei vetoed it so it
 probably won't be added even if somebody created a formal proposal for
 it.


I'm curious, what exactly was proposed?  Because I have a hard time
understanding what's intended from the OP's description.


T

-- 
Obviously, some things aren't very obvious.
Jul 06 2017
parent reply Meta <jared771 gmail.com> writes:
On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 09:42:22PM +0000, Meta via 
 Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:

 Create an auto pointer, handy in some cases and fits in the 
 language as a natural generalization.


 
 It's been suggested before (as well as more powerful 
 generalization for slices and associative arrays), but Andrei 
 vetoed it so it probably won't be added even if somebody 
 created a formal proposal for it.


 I'm curious, what exactly was proposed?  Because I have a hard 
 time understanding what's intended from the OP's description.


 T


Partial type inference. `auto*` declares a point to a type that 
is inferred from inspecting the RHS's type. The previous proposal 
was for doing `auto[] a = [0, 1, 2]` (a's type is inferred as 
int[]).
Jul 06 2017
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 06, 2017 at 10:31:10PM +0000, Meta via Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 09:42:22PM +0000, Meta via Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:

 Create an auto pointer, handy in some cases and fits in the
 language as a natural generalization.


 
 It's been suggested before (as well as more powerful
 generalization for slices and associative arrays), but Andrei
 vetoed it so it probably won't be added even if somebody created a
 formal proposal for it.


 
 I'm curious, what exactly was proposed?  Because I have a hard time
 understanding what's intended from the OP's description.
 
 
 T


 
 Partial type inference. `auto*` declares a point to a type that is
 inferred from inspecting the RHS's type. The previous proposal was for
 doing `auto[] a = [0, 1, 2]` (a's type is inferred as int[]).


But doesn't `auto a = [0, 1, 2];` *already* infer typeof(a) as int[]?
What does `auto[]` add over what `auto` already does?


T

-- 
"Real programmers can write assembly code in any language. :-)" -- Larry Wall
Jul 06 2017
parent reply bauss <jj_1337 live.dk> writes:
On Thursday, 6 July 2017 at 23:12:03 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 10:31:10PM +0000, Meta via 
 Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 09:42:22PM +0000, Meta via 
 Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:

 Create an auto pointer, handy in some cases and fits in 
 the language as a natural generalization.


 
 It's been suggested before (as well as more powerful 
 generalization for slices and associative arrays), but 
 Andrei vetoed it so it probably won't be added even if 
 somebody created a formal proposal for it.


 
 I'm curious, what exactly was proposed?  Because I have a 
 hard time understanding what's intended from the OP's 
 description.
 
 
 T


 
 Partial type inference. `auto*` declares a point to a type 
 that is inferred from inspecting the RHS's type. The previous 
 proposal was for doing `auto[] a = [0, 1, 2]` (a's type is 
 inferred as int[]).


 But doesn't `auto a = [0, 1, 2];` *already* infer typeof(a) as 
 int[]? What does `auto[]` add over what `auto` already does?


 T


It does, but I think it's more a thing of knowing what exactly 
the auto is.

Let's say you have.

auto a = foo();

You have no idea what auto actually is in that case, but

auto* a = foo();

You know auto is a pointer of whatever foo returns.
Jul 06 2017
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Thu, Jul 06, 2017 at 11:50:24PM +0000, bauss via Digitalmars-d wrote:
[...]

 Let's say you have.
 
 auto a = foo();
 
 You have no idea what auto actually is in that case, but
 
 auto* a = foo();
 
 You know auto is a pointer of whatever foo returns.


Ah, I see.  So if foo() doesn't return a pointer it will be a compile
error?  So it's basically a kind of self-documentation?


T

-- 
INTEL = Only half of "intelligence".
Jul 06 2017
next sibling parent bauss <jj_1337 live.dk> writes:
On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 11:50:24PM +0000, bauss via 
 Digitalmars-d wrote: [...]

 Let's say you have.
 
 auto a = foo();
 
 You have no idea what auto actually is in that case, but
 
 auto* a = foo();
 
 You know auto is a pointer of whatever foo returns.


 Ah, I see.  So if foo() doesn't return a pointer it will be a 
 compile error?  So it's basically a kind of self-documentation?


 T


That's my understanding yeah.
Jul 06 2017
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 6 July 2017 at 23:51:13 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 11:50:24PM +0000, bauss via 
 Digitalmars-d wrote: [...]

 Let's say you have.
 
 auto a = foo();
 
 You have no idea what auto actually is in that case, but
 
 auto* a = foo();
 
 You know auto is a pointer of whatever foo returns.


 Ah, I see.  So if foo() doesn't return a pointer it will be a 
 compile error?  So it's basically a kind of self-documentation?


 T


Kenji also extended the inference to some very interesting cases.

     // static array type
     int[$]   a1 = [1,2];    // int[2]
     auto[$]  a2 = [3,4,5];  // int[3]
     const[$] a3 = [6,7,8];  // const(int[3])

     // dynamic array type
     immutable[] a4 = [1,2];    // immutable(int)[]
     shared[]    a5 = [3,4,5];  // shared(int)[]
     // partially specified part is unqualified.

     // pointer type
     auto*  p1 = new int(3);  // int*
     const* p2 = new int(3);  // const(int)*

     // mixing
     auto[][$] x1 = [[1,2,3],[4,5]];  // int[][2]
     shared*[$] x2 = [new int(1), new int(2)];  // shared(int)*[2]

(https://github.com/dlang/dmd/pull/3615)

Of course this could also get confusing pretty fast. I wish we at 
least had the `int[$]` syntax but it's not a huge loss.
Jul 06 2017
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote:

 (https://github.com/dlang/dmd/pull/3615)

 Of course this could also get confusing pretty fast. I wish we 
 at least had the `int[$]` syntax but it's not a huge loss.


Thanks for posting the link. Made for interesting reading.

This was another link on the same topic:
http://forum.dlang.org/post/bewroetnschakoqjzowa forum.dlang.org
Jul 06 2017
parent Meta <jared771 gmail.com> writes:
On Friday, 7 July 2017 at 00:58:57 UTC, jmh530 wrote:

 On Friday, 7 July 2017 at 00:39:32 UTC, Meta wrote:

 (https://github.com/dlang/dmd/pull/3615)

 Of course this could also get confusing pretty fast. I wish we 
 at least had the `int[$]` syntax but it's not a huge loss.


 Thanks for posting the link. Made for interesting reading.

 This was another link on the same topic:
 http://forum.dlang.org/post/bewroetnschakoqjzowa forum.dlang.org


Yeah, it's one of those features that seemed very nice and I, at 
the very least, was disappointed that it didn't get in (of course 
Bearophile was as well). I don't really agree with Andrei's 
reason for vetoing the feature (the part about adding this 
feature being a slippery slope, not the power to complexity 
ratio), but looking back on it there are a few peculiarities with 
this syntax. For example, `immutable[] i = [0]` has the type 
`immutable(int)[]`, but to get `immutable(int[])` you have to do 
`immutable i = [0]`. I'd say that a beginner looking at this code 
would assume the opposite (although it's a very easy rule to 
learn). It's one of the problems D has with this syntax as 
opposed to C++, which has the ability to declare head-const 
arrays/pointers.
Jul 06 2017
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Thursday, 6 July 2017 at 23:50:24 UTC, bauss wrote:

 On Thursday, 6 July 2017 at 23:12:03 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 10:31:10PM +0000, Meta via 
 Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 21:58:45 UTC, H. S. Teoh wrote:

 On Thu, Jul 06, 2017 at 09:42:22PM +0000, Meta via 
 Digitalmars-d wrote:

 On Thursday, 6 July 2017 at 18:10:57 UTC, FoxyBrown wrote:

 Create an auto pointer, handy in some cases and fits in 
 the language as a natural generalization.


 
 It's been suggested before (as well as more powerful 
 generalization for slices and associative arrays), but 
 Andrei vetoed it so it probably won't be added even if 
 somebody created a formal proposal for it.


 
 I'm curious, what exactly was proposed?  Because I have a 
 hard time understanding what's intended from the OP's 
 description.
 
 
 T


 
 Partial type inference. `auto*` declares a point to a type 
 that is inferred from inspecting the RHS's type. The previous 
 proposal was for doing `auto[] a = [0, 1, 2]` (a's type is 
 inferred as int[]).


 But doesn't `auto a = [0, 1, 2];` *already* infer typeof(a) as 
 int[]? What does `auto[]` add over what `auto` already does?


 T


 It does, but I think it's more a thing of knowing what exactly 
 the auto is.

 Let's say you have.

 auto a = foo();

 You have no idea what auto actually is in that case, but

 auto* a = foo();

 You know auto is a pointer of whatever foo returns.


If you want to document the type returned, then use an explicit 
type. Type deduction is imho a thing to avoid redundancy in an 
expression, not to transform D into python (and to make templates 
possible). If the type of an expression becomes difficult to 
deduce, it is a good idea imo to explicitely write out the type. 
This adds a simple constraint, i.e. adds a way for the compiler 
to exploit the type system to make the program more secure.
Jul 06 2017