July 06, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to bauss | 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". |
July 07, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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.
|
July 07, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to H. S. Teoh | 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. |
July 07, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to Meta | 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 |
July 07, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to jmh530 | 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.
|
July 07, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to FoxyBrown | 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.
|
July 07, 2017 Re: auto* | ||||
---|---|---|---|---|
| ||||
Posted in reply to bauss | 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.
|
Copyright © 1999-2021 by the D Language Foundation