On 2020-05-09 05:04, Walter Bright wrote:

> Keep in mind that as of recently, AliasSeq!(1,2,3) generates a tuple directly without going through the template instantiation mechanism.

For first class support for tuples it would be really nice to support named elements in the tuple: `(foo: 1, bar: 2, baz: 3)`, which `AliasSeq` does not support.

This could also be used to solve the major complaint about removing the struct static initialization syntax.

struct Point
{
    int x;
    int y;
}

Today:

Point a = { x: 3, y: 4 };

With first class tuples with named elements:

auto b = (x: 3, y: 4);
static assert(is(typeof(a) == (int, int));

Point c = (x: 3, y: 4);
Point d = b; // possibly allow this

For this small example it might not matter but there are bigger examples [1].

[1] https://forum.dlang.org/post/aqgvlgpjbwdhrxuoezjs@forum.dlang.org

-- 
/Jacob Carlborg

On 5/8/2020 11:37 PM, Jacob Carlborg wrote:
> For first class support for tuples it would be really nice to support named elements in the tuple: `(foo: 1, bar: 2, baz: 3)`, which `AliasSeq` does not support.

That would be named arguments for templates.

On Sat, May 9, 2020 at 2:45 PM Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On 5/8/2020 9:36 PM, Manu wrote:
> > It's still hideous though. Fundamental language features would ideally
> be
> > acknowledged and speced rather than expressed incidentally by an ugly
> hack.
>
> We can defer this discussion until the DIP is presented. But the existence
> of
> the AliasSeq should be discussed in the DIP as an alternative.
>

For instance, it would be nice for a function to return a tuple:
  AliasSeq!(int, float) mrv() { return AliasSeq!(1, 1.0f); }

But that doesn't really make sense from the perspective of the template arg
list hack we use, relative to a proper language tuple.
Instead we use a struct named `Tuple`, which isn't a tuple, it's a struct,
and it infers a lot about ABI, move/copy semantics, etc.

On Friday, 8 May 2020 at 22:20:03 UTC, Timon Gehr wrote:
> On 08.05.20 22:38, 12345swordy wrote:
>> As I am working on the "Tuples first class feature" dip (will uploaded first draft soon), I noticed that if we would allow this in D:
>> 
>> fun((int x = 10, int y = 1, int z = 2)...);
>> 
>> Could this be used as a replacement for named arguments?
>
> No, too ugly. Anyway, there should not be a difference in features for tuples and multiple function arguments. In mathematics, those are the same thing. (I.e. each function has one parameter, which may be a tuple.) Ideally, built-in tuples and multiple function arguments should interact in a way that is consistent with this principle.

In mathematics you don't have function overloading. I believe this could cause ambiguities if tuple parameters are automatically "unpacked".

On 09.05.20 15:19, Mark wrote:
> On Friday, 8 May 2020 at 22:20:03 UTC, Timon Gehr wrote:
>> On 08.05.20 22:38, 12345swordy wrote:
>>> As I am working on the "Tuples first class feature" dip (will uploaded first draft soon), I noticed that if we would allow this in D:
>>>
>>> fun((int x = 10, int y = 1, int z = 2)...);
>>>
>>> Could this be used as a replacement for named arguments?
>>
>> No, too ugly. Anyway, there should not be a difference in features for tuples and multiple function arguments. In mathematics, those are the same thing. (I.e. each function has one parameter, which may be a tuple.) Ideally, built-in tuples and multiple function arguments should interact in a way that is consistent with this principle.
> 
> In mathematics you don't have function overloading. I believe this could cause ambiguities if tuple parameters are automatically "unpacked".

You can easily have function overloading and fully sane tuple semantics at the same time. It is true that in D, some compromises might have to be made in order to preserve backwards compatibility. I think my attempt [1] [2] does that quite well, but maybe there is an even better way.



[1] https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md (Proposal 2)
[2] https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax

On Saturday, 9 May 2020 at 14:28:37 UTC, Timon Gehr wrote:
> You can easily have function overloading and fully sane tuple semantics at the same time. It is true that in D, some compromises might have to be made in order to preserve backwards compatibility. I think my attempt [1] [2] does that quite well, but maybe there is an even better way.

I wish what you proposed there is already in D... Was there a real DIP created out of that?

On 09.05.20 17:21, Dejan Lekic wrote:
> On Saturday, 9 May 2020 at 14:28:37 UTC, Timon Gehr wrote:
>> You can easily have function overloading and fully sane tuple semantics at the same time. It is true that in D, some compromises might have to be made in order to preserve backwards compatibility. I think my attempt [1] [2] does that quite well, but maybe there is an even better way.
> 
> I wish what you proposed there is already in D... Was there a real DIP created out of that?

Unfortunately I got too busy with work and never finished the DIP nor its implementation. :/ I had originally intended to work on this during DConf 2018, but Andrei wanted me to work on "__mutable" instead as it would be more "impactful" work. Of course, he then went on and killed "__mutable".

On Saturday, 9 May 2020 at 14:28:37 UTC, Timon Gehr wrote:
> On 09.05.20 15:19, Mark wrote:
>> In mathematics you don't have function overloading. I believe this could cause ambiguities if tuple parameters are automatically "unpacked".
>
> You can easily have function overloading and fully sane tuple semantics at the same time. It is true that in D, some compromises might have to be made in order to preserve backwards compatibility. I think my attempt [1] [2] does that quite well, but maybe there is an even better way.
>
>
>
> [1] https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md (Proposal 2)
> [2] https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax

Personally, I like how Python does it - you have to unpack tuples manually but the syntax is extremely terse (*mytuple). It also supports "dictionary unpacking", which allows passing named parameters to functions elegantly, again with very little syntactic overhead (**mydict).

On 5/9/2020 12:08 AM, Manu wrote:
> For instance, it would be nice for a function to return a tuple:
>    AliasSeq!(int, float) mrv() { return AliasSeq!(1, 1.0f); }
> 
> But that doesn't really make sense from the perspective of the template arg list hack we use, relative to a proper language tuple.
> Instead we use a struct named `Tuple`, which isn't a tuple, it's a struct, and it infers a lot about ABI, move/copy semantics, etc.

D already merges the notion of a struct and an array, e.g.:

   struct S { int a,b,c; }
   int[3] a;

are passed/returned in an identical manner. (Went to considerable effort to make this happen.) I wished to have it include:

   AliasSeq!(1, 2, 3)

behaving the same way. But, alas, the function ABI makes that impossible. struct S is passed to a function *differently* from 1,2,3, and a tuple parameter is the same as 1,2,3, not like a struct literal {1,2,3}.

On 09.05.20 19:07, Mark wrote:
> On Saturday, 9 May 2020 at 14:28:37 UTC, Timon Gehr wrote:
>> On 09.05.20 15:19, Mark wrote:
>>> In mathematics you don't have function overloading. I believe this could cause ambiguities if tuple parameters are automatically "unpacked".
>>
>> You can easily have function overloading and fully sane tuple semantics at the same time. It is true that in D, some compromises might have to be made in order to preserve backwards compatibility. I think my attempt [1] [2] does that quite well, but maybe there is an even better way.
>>
>>
>>
>> [1] https://github.com/tgehr/DIPs/blob/tuple-syntax/DIPs/DIP1xxx-tg.md (Proposal 2)
>> [2] https://github.com/dlang/dmd/compare/master...tgehr:tuple-syntax
> 
> Personally, I like how Python does it - you have to unpack tuples manually

I don't see any reason why the concept "multiple function arguments" should be separate from the concept "multiple tuple elements". It's a distinction without a difference and I think it is a design mistake.

> but the syntax is extremely terse (*mytuple).

def foo(x, y):
    return x + y

print(map(foo, [(1, 2), (3, 4)])) # without unpacking, does not work

# manual unpacking, kind of not "extremely terse":
print(list(map(lambda t: foo(*t), [(1, 2), (3, 4)])))


std.typecons.tuple allows expansion with using the notation `mytuple[]` (but this is kind of an accident), and it suffers from the same issue that Python does.

> It also supports "dictionary unpacking", which allows passing named parameters to functions elegantly, again with very little syntactic overhead (**mydict).

Yes, unfortunately so far this concept has been missing from named argument DIPs.