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

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.

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.

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

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.

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.

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.