www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Allow Explicit Pointer for Auto Declaration

reply Jacob <noreply noreply.com> writes:
Was wondering if this feature could be implemented, right now 
auto needs to be written like this:

     auto pValue = someFunctionReturnsRef(); // forgot '&', still 
valid
                                             // makes a copy when 
we didn't want one

The feature would make the code look like this:

     auto* pValue = someFunctionReturnsRef(); // error expecting 
pointer

We don't accidentally make a copy when we wanted a pointer. C++ 
has a similar semantic for it's auto.
Sep 29 2016
next sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/29/16 7:42 PM, Jacob wrote:

 Was wondering if this feature could be implemented, right now auto needs
 to be written like this:

     auto pValue = someFunctionReturnsRef(); // forgot '&', still valid
                                             // makes a copy when we
 didn't want one

 The feature would make the code look like this:

     auto* pValue = someFunctionReturnsRef(); // error expecting pointer

 We don't accidentally make a copy when we wanted a pointer. C++ has a
 similar semantic for it's auto.


Hm... I'm not familiar with C++ auto, but C++ does have local 
references. D does not.

I'm not sure if you are asking for the syntax specified, or asking for 
the original line to be treated like the specified syntax. The latter 
absolutely is not going to happen, because that breaks valid code.

Even if we added:

auto* pValue = expr;

I don't see why this is more advantageous than:

auto pValue = &expr;

-Steve
Sep 29 2016
parent reply Jacob <noreply noreply.com> writes:
On Friday, 30 September 2016 at 00:05:45 UTC, Steven 
Schveighoffer wrote:

 On 9/29/16 7:42 PM, Jacob wrote:

 Was wondering if this feature could be implemented, right now 
 auto needs
 to be written like this:

     auto pValue = someFunctionReturnsRef(); // forgot '&', 
 still valid
                                             // makes a copy 
 when we
 didn't want one

 The feature would make the code look like this:

     auto* pValue = someFunctionReturnsRef(); // error 
 expecting pointer

 We don't accidentally make a copy when we wanted a pointer. 
 C++ has a
 similar semantic for it's auto.


 Hm... I'm not familiar with C++ auto, but C++ does have local 
 references. D does not.

 I'm not sure if you are asking for the syntax specified, or 
 asking for the original line to be treated like the specified 
 syntax. The latter absolutely is not going to happen, because 
 that breaks valid code.

 Even if we added:

 auto* pValue = expr;

 I don't see why this is more advantageous than:

 auto pValue = &expr;

 -Steve


auto* pValue = expr;  // still invalid code unless expr evaluate 
to a pointer type
auto* pValue = &expr; // this is valid if expr is a ref

It still requires the &, what it prevents is this situation:

auto pValue = expr; // wanted pointer, expr evaluates to non-ptr 
value through change of code or simply forgetting "&"

So no code should be broken, you can do everything the same way 
without a change in behavior and auto with a "*" is currently 
invalid.

Basically how it works in C++: http://ideone.com/TUz9dO
Sep 29 2016
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Friday, 30 September 2016 at 01:48:02 UTC, Jacob wrote:


 auto* pValue = expr;  // still invalid code unless expr 
 evaluate to a pointer type
 auto* pValue = &expr; // this is valid if expr is a ref

 It still requires the &, what it prevents is this situation:

 auto pValue = expr; // wanted pointer, expr evaluates to 
 non-ptr value through change of code or simply forgetting "&"

 So no code should be broken, you can do everything the same way 
 without a change in behavior and auto with a "*" is currently 
 invalid.

 Basically how it works in C++: http://ideone.com/TUz9dO


You could forget the * just as easily as the &.
Sep 29 2016
parent Jacob <noreply noreply.com> writes:
On Friday, 30 September 2016 at 03:07:41 UTC, Mike Parker wrote:

 On Friday, 30 September 2016 at 01:48:02 UTC, Jacob wrote:


 auto* pValue = expr;  // still invalid code unless expr 
 evaluate to a pointer type
 auto* pValue = &expr; // this is valid if expr is a ref

 It still requires the &, what it prevents is this situation:

 auto pValue = expr; // wanted pointer, expr evaluates to 
 non-ptr value through change of code or simply forgetting "&"

 So no code should be broken, you can do everything the same 
 way without a change in behavior and auto with a "*" is 
 currently invalid.

 Basically how it works in C++: http://ideone.com/TUz9dO


 You could forget the * just as easily as the &.


Easier to notice and to check whether the type is a pointer.
Sep 29 2016
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/29/16 9:48 PM, Jacob wrote:

 It still requires the &, what it prevents is this situation:

 auto pValue = expr; // wanted pointer, expr evaluates to non-ptr value
 through change of code or simply forgetting "&"


Wait, what happens when you do that? If that's now an error, this is a 
non-starter.

-Steve
Sep 29 2016
next sibling parent Jacob <noreply noreply.com> writes:
On Friday, 30 September 2016 at 05:01:52 UTC, Steven 
Schveighoffer wrote:

 On 9/29/16 9:48 PM, Jacob wrote:

 It still requires the &, what it prevents is this situation:

 auto pValue = expr; // wanted pointer, expr evaluates to 
 non-ptr value
 through change of code or simply forgetting "&"


 Wait, what happens when you do that? If that's now an error, 
 this is a non-starter.

 -Steve


I said before it doesn't break existing code. Like before, you 
can do everything the same way without a change in behavior and 
auto with a "*" is currently invalid.
Sep 30 2016
prev sibling parent Olivier Grant <foo bar.com> writes:
On Friday, 30 September 2016 at 05:01:52 UTC, Steven 
Schveighoffer wrote:

 On 9/29/16 9:48 PM, Jacob wrote:

 It still requires the &, what it prevents is this situation:

 auto pValue = expr; // wanted pointer, expr evaluates to 
 non-ptr value
 through change of code or simply forgetting "&"


 Wait, what happens when you do that? If that's now an error, 
 this is a non-starter.

 -Steve


Jacob is simply asking that you may explicit the fact that you 
expect the right hand side of the assignment to evaluate to a 
pointer while still using the type deduction offered by 'auto'.

auto p = expr;

Depending on the return type of expr, p's type can be either a 
pointer or a copy.

auto *p = expr;

Imposes that expr evaluate to a pointer.

Although the former is valid in C++ whatever expr evaluates to, I 
always use the latter when I expect expr to evaluate to a 
pointer. It also add consistency with 'auto &'.
Sep 30 2016
prev sibling parent reply Meta <jared771 gmail.com> writes:
On Thursday, 29 September 2016 at 23:42:29 UTC, Jacob wrote:

 Was wondering if this feature could be implemented, right now 
 auto needs to be written like this:

     auto pValue = someFunctionReturnsRef(); // forgot '&', 
 still valid
                                             // makes a copy 
 when we didn't want one

 The feature would make the code look like this:

     auto* pValue = someFunctionReturnsRef(); // error expecting 
 pointer

 We don't accidentally make a copy when we wanted a pointer. C++ 
 has a similar semantic for it's auto.


This suggestion has come up before but Andrei is against it.

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

It brings a tear to my eye.
Sep 30 2016
parent Jacob <noreply noreply.com> writes:
On Friday, 30 September 2016 at 13:37:43 UTC, Meta wrote:

 This suggestion has come up before but Andrei is against it.

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

 It brings a tear to my eye.


Ah that's a shame, would like to reopen that conversation. Is 
there any way to ping him on the forums. I can see his case for 
not wanting "[$]" arrays, but I feel it's a different case for 
pointers.


Andralex on github:

 Complicates the language without a corresponding increase in 
 power


I'd say it increases readability and maintainability, that may 
not be an increase in "power" (what does that even mean) but I'd 
argue maintainability and readability are more important than 
"power". When you see "auto" you can't infer any information 
about it making it harder to read code. Adding some extra 
information to it can make it more readable at a glance.


 Small obscure feature of dubious usefulness that creates a 
 precedent for other small obscure features of increasingly 
 dubious usefulness


This functionality already exists in function form as seen below. 
So the foot is already in the door, it's a matter adding the 
functionality to auto declarations, for completeness and such ;).


 How about accepting stuff like that in function parameters, 
 etc? It's easy to argue that on grounds of completeness, now 
 that there's a foot in the door.


Ref as well. The functionality of reference is almost exactly a 
partial type specification. As in C++ a reference is denoted by 
"&", when you look at the implementaiton in C++ they are almost 
exactly the same.

for(auto* v : args);
for(auto& v : args);

So the functionality already exists as a reference as well. It 
exists in a function parameter as well as in a foreach statement. 
Basically everywhere that you made the argument against the 
feature, as it could extend to those areas as well. The only 
place "ref" doesn't exist in D is when specifying a variable. 
Otherwise it's almost exactly the same feature.



     import std.stdio;

     void test(T)(T* t) // functionality already exists in 
function form
     {
         writeln(T.stringof);
     }

     void main()
     {
         int* p;

         test(p);
         // test(10); // error won't compile this

         foreach(ref v ; 0 .. 10) // basically equivalent to C++: 
for(auto& v : arr)
         {
         }
     }
Sep 30 2016