Timon Gehr:

> 4 There is no way to capture the part matched by "..."

I have suggested to move the ... syntax to a Stage2, a different DEP.


> 5 .expand (or similar) property is missing.

I think Kenji has suggested to use a trailing [] for that.

Bye,
bearophile

On 03/29/2013 01:49 PM, Adam D. Ruppe wrote:
> My first thought when I saw {} was json. This is getting a little
> further away from tuples, but would it be hard to add named fields to
> this too like json:
>
> auto a = {"foo":12, "bar":"twelve"};
>
> int a_foo = a.foo;
> string a_bar = a[1];
>
>
> The std.typecons Tuple!() can do this kind of thing too.

Remove the quotes and it looks like a struct literal.

I think if named fields are allowed, it should look as follows:

auto a = {foo: 12, bar: "twelve"};

Simen Kjærås:

>> void foo(t2@{int a, string b}) {
>>    // here a and b are tuple items and t2 is the whole tuple.
>> }
>> auto t1@{x, y} = {10, "hi"};
>> foo(t1);
>
> I suggest instead this syntax:
>
> auto {x, y} t1 = {10, "hi"};
>
> It's closer to regular D syntax.

But I'd like sometime to tie t1 to that {}, to help my eyes.



>> {c, $_} = tup;
>> {c, @} = tup;
>> {c, @_} = tup;
>> {c, $$} = tup;
>> ...
>> {c, {_}} = tup;
>> {c, $~} = tup;
>> ...
>> etc.
>
> ... has been introduced to match zero or more elements for pattern matching
> already. I see no reason not to use ... for this.

Telling the language that there there is exactly one item to match on, that you don't care of, is important. The "..." syntax can't tell apart the case for zero, one, or more items. So "..." can't be enough here.

Bye,
bearophile

On 03/29/2013 02:25 PM, bearophile wrote:
> Timon Gehr:
>
>> 4 There is no way to capture the part matched by "..."
>
> I have suggested to move the ... syntax to a Stage2, a different DEP.
>
>
>> 5 .expand (or similar) property is missing.
>
> I think Kenji has suggested to use a trailing [] for that.
> ...

No, please. Slicing should not auto-expand.

Leading to:

8 Slicing operations on tuples missing.

On 03/29/2013 02:17 PM, Simen Kjærås wrote:
> On Fri, 29 Mar 2013 13:56:08 +0100, bearophile
> <bearophileHUGS@lycos.com> wrote:
>
>> One handy tuple syntax in Haskell allows you to name both the items of
>> a tuple and it whole:
>>
>>
>> void foo(t2@{int a, string b}) {
>>     // here a and b are tuple items and t2 is the whole tuple.
>> }
>> auto t1@{x, y} = {10, "hi"};
>> foo(t1);
>
> I suggest instead this syntax:
>
> auto {x, y} t1 = {10, "hi"};
>
> It's closer to regular D syntax.
> ...

It is already taken and equivalent to:

{x, y} t1 = {10, "hi"};

On 03/29/2013 01:56 PM, bearophile wrote:
> kenji hara:
>
>> ...
>> Use braces and commas. Inside tuple literal, ; never appears. So it
>> will not be confused with lambdas and ScopeStatements.<
>
> This is true. ...

It is false.

On 03/29/2013 02:20 PM, Timon Gehr wrote:
> ...
>
> 0 "Inside tuple literal, ; never appears."
>    {{;}}           // a tuple not matching your specification
>    {{if(foo()){}}} // a non-tuple matching your specification
> ...

The outer { } are not necessary in order to make the point:
 {if(foo()){}}

For tuple values with named fields, we need more thoughts about semantics.

alias MyPair = typeof({1, "hi"});
alias MyRecord = typeof({count:1, msg:"hi"});
static assert(is(MyPair == MyRecord));  // true or false?
static assert(is(MyPair  : MyRecord));  // true or false?
static assert(is(MyRecord  : MyPair));  // true or false?
alias MyStudent = typeof({num:1, name:"John"});
static assert(is(MyRecord == MyStudent));  // true or false?

Kenji Hara


2013/3/29 Adam D. Ruppe <destructionator@gmail.com>

> My first thought when I saw {} was json. This is getting a little further away from tuples, but would it be hard to add named fields to this too like json:
>
> auto a = {"foo":12, "bar":"twelve"};
>
> int a_foo = a.foo;
> string a_bar = a[1];
>
>
> The std.typecons Tuple!() can do this kind of thing too.
>

On Friday, 29 March 2013 at 14:57:33 UTC, kenji hara wrote:
> For tuple values with named fields, we need more thoughts about semantics.

Tuples with named fields are records. Once we have a unpacking syntax, the names become less needed. I suggest to leave field names to the Stage2.

Bye,
bearophile

Once tuples have a built-in syntax it becomes possible to add pairs/byPair to associative arrays:


auto aa = [1:2, 3:4];
{int, int}[] myPairs1 = aa.pairs;
foreach ({k, v}; myPairs1) {}
auto myPairs2 = aa.byPair;
foreach ({k, v}; myPairs2) {}

Bye,
bearophile