Thread overview
Allow Explicit Pointer for Auto Declaration
Sep 29, 2016
Jacob
Sep 30, 2016
Jacob
Sep 30, 2016
Mike Parker
Sep 30, 2016
Jacob
Sep 30, 2016
Jacob
Sep 30, 2016
Olivier Grant
Sep 30, 2016
Meta
Sep 30, 2016
Jacob
September 29, 2016
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.



September 29, 2016
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
September 30, 2016
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


September 30, 2016
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 &.
September 30, 2016
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.
September 30, 2016
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
September 30, 2016
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.
September 30, 2016
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 &'.
September 30, 2016
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.
September 30, 2016
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)
        {
        }
    }