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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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