March 31, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Kagamin | On 03/31/2013 08:20 PM, Kagamin wrote:
> On Friday, 29 March 2013 at 15:47:52 UTC, Timon Gehr wrote:
>>> template X(T...) {}
>>> alias x = X!(int, long); // T captures {int, long}
>>>
>>
>> Not really. T captures {int, long}.expand.
>
> Should there be a difference?
Sure.
|
April 01, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | On Friday, 29 March 2013 at 08:58:06 UTC, kenji hara wrote:
> http://wiki.dlang.org/DIP32
>
> Kenji Hara
Why not square brackets?
int i;
string str;
[i, str] = [5, "line"];
Tuple as alias to Object[] or to Variant[].
|
April 01, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Traveler | On Mon, 01 Apr 2013 09:08:47 +0200, Traveler <nooneknows@example.com> wrote: > On Friday, 29 March 2013 at 08:58:06 UTC, kenji hara wrote: >> http://wiki.dlang.org/DIP32 >> >> Kenji Hara > > Why not square brackets? > > int i; > string str; > > [i, str] = [5, "line"]; > > Tuple as alias to Object[] or to Variant[]. Mostly because it already has a meaning in D, namely that of an array. What you have above certainly does not compile, but consider the case of a homogeneous tuple: int i = 1, j = 2; [i, j] = [3, 4]; This is equivalent to this code: [1, 2] = [3, 4]; Which of course is nonsense, but it already has a meaning. Using an existing syntax leads to many many more corner cases and gray areas than creating a new syntax does. Of course, {} also has a meaning already, but the overlap of semantics is much smaller, and thus the potential corner cases and gray areas are fewer and smaller. -- Simen |
April 01, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | By the way, {int,int} - is it a type or a value? auto t={int,int}; t[1] a; ^what is this? 1-element array of {int,int} tuples or `int a;` ? |
April 02, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to kenji hara | Two different languages I've used in the distant past used @ for expansion. auto t1 = {1, "hi"}; auto t2 = {2, "yo"}; auto t3 = {t1, t2}; // == {{1, "hi"}, {2, "yo"}} auto t4 = {@t1, @t2}; // == {1, "hi", 2, "yo"} Are there still unspecified plans for @, or is it now available for something like this? Regarding the $ident syntax (which I was glad to see, since my first question when reading the DIP was whether a way existed to do that), couldn't the @ syntax then be allowed for this as well, with expansion of a scalar defined as the scalar itself? int x = 1; if ( auto {@x, y} = tmp ) // {1, y} = tmp if ( auto {x, y} = tmp } // same as in DIP |
April 02, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Nicholson-Sauls | On 2013-04-02 02:16, Chris Nicholson-Sauls wrote: > Two different languages I've used in the distant past used @ for expansion. > > auto t1 = {1, "hi"}; > auto t2 = {2, "yo"}; > > auto t3 = {t1, t2}; // == {{1, "hi"}, {2, "yo"}} > auto t4 = {@t1, @t2}; // == {1, "hi", 2, "yo"} > > Are there still unspecified plans for @, or is it now available for > something like this? > > Regarding the $ident syntax (which I was glad to see, since my first > question when reading the DIP was whether a way existed to do that), > couldn't the @ syntax then be allowed for this as well, with expansion > of a scalar defined as the scalar itself? > > int x = 1; > if ( auto {@x, y} = tmp ) // {1, y} = tmp > > if ( auto {x, y} = tmp } // same as in DIP Won't there be a conflict with UDA's? -- /Jacob Carlborg |
April 02, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to Jacob Carlborg | On Tuesday, 2 April 2013 at 06:42:00 UTC, Jacob Carlborg wrote:
> On 2013-04-02 02:16, Chris Nicholson-Sauls wrote:
>> Two different languages I've used in the distant past used @ for expansion.
>>
>> auto t1 = {1, "hi"};
>> auto t2 = {2, "yo"};
>>
>> auto t3 = {t1, t2}; // == {{1, "hi"}, {2, "yo"}}
>> auto t4 = {@t1, @t2}; // == {1, "hi", 2, "yo"}
>>
>> Are there still unspecified plans for @, or is it now available for
>> something like this?
>>
>> Regarding the $ident syntax (which I was glad to see, since my first
>> question when reading the DIP was whether a way existed to do that),
>> couldn't the @ syntax then be allowed for this as well, with expansion
>> of a scalar defined as the scalar itself?
>>
>> int x = 1;
>> if ( auto {@x, y} = tmp ) // {1, y} = tmp
>>
>> if ( auto {x, y} = tmp } // same as in DIP
>
> Won't there be a conflict with UDA's?
Oh yeah, those exist. (I seriously forgot... just because I haven't gotten to play with recent D releases any.)
|
April 05, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Saturday, 30 March 2013 at 18:05:27 UTC, bearophile wrote: > Zach the Mystic: > >>> {c, $_} = tup; >>> {c, @} = tup; >>> {c, @_} = tup; >>> {c, $$} = tup; >>> {c, {}} = tup; >>> {c, {_}} = tup; >>> {c, $~} = tup; >>> {c, @~= tup; >>> etc. >> >> {c, ?} = tup; > > Right, I was forgetting that. > Or this if you want to keep the single "?" for hypothetical future nullable types: > > {c, ?_} = tup; What about ---- {c, void} = tup; ---- (proposed by Hara Kenji in the original AutoTupleDeclaration declaration pull request https://github.com/D-Programming-Language/dmd/pull/341 ) (and, independently of the missing symbol choice) ---- {a,b,void...} = tup; //tup = {1,2,3,4,5}; ---- |
April 05, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to timotheecour | timotheecour:
> What about
> ----
> {c, void} = tup;
I think the question mark is better here. It's shorter and it has only one meaning.
Bye,
bearophile
|
April 06, 2013 Re: DIP32: Uniform tuple syntax | ||||
---|---|---|---|---|
| ||||
Posted in reply to bearophile | On Friday, 5 April 2013 at 23:49:49 UTC, bearophile wrote:
> timotheecour:
>
>> What about
>> ----
>> {c, void} = tup;
>
> I think the question mark is better here. It's shorter and it has only one meaning.
>
> Bye,
> bearophile
Not disagreeing, but you had mentioned nullable types before, and I was wondering what they might look like also. Have you made an enhancement for these I could examine?
|
Copyright © 1999-2021 by the D Language Foundation