www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Tuples a first class feature, manu's new unary operator and named

reply 12345swordy <alexanderheistermann gmail.com> writes:
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? It would 
address the readability problem certainly. However it doesn't 
address the default argument values that certain functions have. 
I.E.

void sub(int x, int y = -1, int z) { ... }

if that were the case why not allow tuples such that

sub((int x = 0, int z = 0)...) = sub(0, -1, 0)

It will attempted to map tuple variables to function argument 
based on the named values. Then I realize that it will ran into 
the same issue with name arguments by default as that when the 
function arguments name been changed it will break users code, so 
no dice there.

Any thoughts on this? Right now, my dip is nothing more than much 
needed syntax sugar for tuples.

-Alex
May 08 2020
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.


 It would 
 address the readability problem certainly. However it doesn't address 
 the default argument values that certain functions have. I.E.
 
 void sub(int x, int y = -1, int z) { ... }
 
 if that were the case why not allow tuples such that
 
 sub((int x = 0, int z = 0)...) = sub(0, -1, 0)
 
 It will attempted to map tuple variables to function argument based on 
 the named values. Then I realize that it will ran into the same issue 
 with name arguments by default as that when the function arguments name 
 been changed it will break users code, so no dice there.
 ...


That's true even now, so this is not a strong argument. The problem is 
that existing names are inconsistent because naming is hard and the 
authors were not aware that function names are part of the public API. 
Attributing this situation to named arguments is simply a mistake.


 Any thoughts on this? Right now, my dip is nothing more than much needed 
 syntax sugar for tuples.
 
 -Alex


I don't see why you would start a new DIP instead of forking mine, but 
in any case, syntax for a named argument tuple should be (x: 0, z: 0), 
not (int x = 0, int z = 0).
May 08 2020
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Friday, 8 May 2020 at 22:20:03 UTC, Timon Gehr wrote:

 On 08.05.20 22:38, 12345swordy wrote:

 [...]


 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.


 [...]


 That's true even now, so this is not a strong argument. The 
 problem is that existing names are inconsistent because naming 
 is hard and the authors were not aware that function names are 
 part of the public API. Attributing this situation to named 
 arguments is simply a mistake.


 [...]


 I don't see why you would start a new DIP instead of forking 
 mine, but in any case, syntax for a named argument tuple should 
 be (x: 0, z: 0), not (int x = 0, int z = 0).


I do not see anyone done that before, so I assume that was 
consider it to be a bad thing. Looks like you give me permission 
then to fork it then. I will give it some needed polish.

-Alex
May 08 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09.05.20 00:29, 12345swordy wrote:

 On Friday, 8 May 2020 at 22:20:03 UTC, Timon Gehr wrote:

 On 08.05.20 22:38, 12345swordy wrote:

 [...]


 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.


 [...]


 That's true even now, so this is not a strong argument. The problem is 
 that existing names are inconsistent because naming is hard and the 
 authors were not aware that function names are part of the public API. 
 Attributing this situation to named arguments is simply a mistake.


 [...]


 I don't see why you would start a new DIP instead of forking mine, but 
 in any case, syntax for a named argument tuple should be (x: 0, z: 0), 
 not (int x = 0, int z = 0).


 
 I do not see anyone done that before,


Actually, Andrei and Razvan forked my draft for the `__mutable` DIP [1] 
but I asked to be removed from the list of authors as they changed it to 
the point where it was no longer the same feature and I no longer 
supported it.


 so I assume that was consider it to be a bad thing.


On the contrary. Forking is a very productive form of collaboration. 
It's licensed under CC0 where copyright belongs to the D language 
foundation. The only reason I wrote it is so we may get the feature. 
It's nice that you are able to invest time towards getting some 
first-class tuple support into the language.


 Looks like you give me permission then to fork it 
 then. I will give it some needed polish.
 
 -Alex


Great. :)


[1] https://github.com/RazvanN7/DIPs/blob/Mutable_Dip/DIPs/DIP1xxx-rn.md
May 08 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2020 3:20 PM, 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.


This is already the case in D:

   fun(AliasSeq!(10,1,2))

is the same as

   fun(10,1,2)
May 08 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09.05.20 05:03, Walter Bright wrote:

 On 5/8/2020 3:20 PM, 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.


 
 This is already the case in D:
 
    fun(AliasSeq!(10,1,2))
 
 is the same as
 
    fun(10,1,2)


I know that you call this a tuple, but it was renamed in Phobos.
This thread is about first-class language support for something like 
std.typecons.Tuple.
May 08 2020
prev sibling parent reply Mark <smarksc gmail.com> writes:
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".
May 09 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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
May 09 2020
next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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?
May 09 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
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".
May 09 2020
prev sibling parent reply Mark <smarksc gmail.com> writes:
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).
May 09 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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(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.
May 09 2020
next sibling parent reply Panke <tobias pankrath.net> writes:
On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:

 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 that would mean we need a way to prevent a tuple from 
unpacking automatically, wouldn't it?

Or do we only allow exactly one or no tuple in an argument list?
May 10 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10.05.20 09:00, Panke wrote:

 On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:

 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 that would mean we need a way to prevent a tuple from unpacking 
 automatically, wouldn't it?
 ...


It does not mean that, because there would be no "unpacking".

The way to think about it is that every function has precisely one argument:

def f(t):
     return t[0] + t[1]

Then there is syntactic sugar. The following definition

def f(a, b){
     return a + b

Would actually mean:

def f(t):
     (a, b) = t
     return a + b

I.e., multiple function arguments are a pattern to which you match a 
tuple. You can then call the function with a tuple:

t = (1, 2)
f(t)





In the grammar, a function call would be a function followed by a 
standard parenthesized expression. You literally parse the same thing 
after a function call as when you encounter parentheses in an expression.


 Or do we only allow exactly one or no tuple in an argument list?
 
 


You would be able to match as many tuples as you like, e.g.:

def f(a, (b, c)):
     return a + b + c



A parameter list is just a pattern to match an argument to.
May 10 2020
parent M.M. <matus email.cz> writes:
On Sunday, 10 May 2020 at 17:47:12 UTC, Timon Gehr wrote:

 On 10.05.20 09:00, Panke wrote:

 [...]


 It does not mean that, because there would be no "unpacking".

 The way to think about it is that every function has precisely 
 one argument:

 [...]


Yup! Tuples just like in mathematics! +1
May 10 2020
prev sibling parent reply Mark <smarksc gmail.com> writes:
On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:

 On 09.05.20 19:07, Mark wrote:

 but the syntax is extremely terse (*mytuple).


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


 work


 print(list(map(lambda t: foo(*t), [(1, 2), (3, 4)])))


Hmmm, very good point.

The issue seems similar (at least in spirit) to that of implicit 
casting. Implicit casting is, in a sense, syntactic sugar, saving 
you from writing "cast(mytype) myval" all over the place. It's 
also a highly contentious issue; everyone seems to be have their 
opinion of the extent to which implicit casting is a good thing.
May 10 2020
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 10.05.20 14:06, Mark wrote:

 On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:

 On 09.05.20 19:07, Mark wrote:

 but the syntax is extremely terse (*mytuple).


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




 print(list(map(lambda t: foo(*t), [(1, 2), (3, 4)])))


 
 Hmmm, very good point.
 
 The issue seems similar (at least in spirit) to that of implicit 
 casting. Implicit casting is, in a sense, syntactic sugar, saving you 
 from writing "cast(mytype) myval" all over the place. It's also a highly 
 contentious issue; everyone seems to be have their opinion of the extent 
 to which implicit casting is a good thing.


It's not really similar. The problem is that there are two different 
things that are actually the same but still formally require conversion 
between each other. It's busywork without a justification.

Consider the following analogy. Let's say we introduce a new built-in 
type `Int` to D. It behaves precisely the same as `int`, but values of 
type `int` and type `Int` are incompatible. Do you think that's a good 
idea? Do you think that instead just not doing so raises any of the 
concerns around implicit casting? Do you think anyone would argue e.g. 
Rust has too liberal implicit casting because they do not have this kind 
of equivalent yet incompatible built-in types?
May 10 2020
parent reply Mark <smarksc gmail.com> writes:
On Sunday, 10 May 2020 at 17:56:22 UTC, Timon Gehr wrote:

 On 10.05.20 14:06, Mark wrote:

 On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:

 On 09.05.20 19:07, Mark wrote:

 but the syntax is extremely terse (*mytuple).


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


 not work


 print(list(map(lambda t: foo(*t), [(1, 2), (3, 4)])))


 
 Hmmm, very good point.
 
 The issue seems similar (at least in spirit) to that of 
 implicit casting. Implicit casting is, in a sense, syntactic 
 sugar, saving you from writing "cast(mytype) myval" all over 
 the place. It's also a highly contentious issue; everyone 
 seems to be have their opinion of the extent to which implicit 
 casting is a good thing.


 It's not really similar. The problem is that there are two 
 different things that are actually the same but still formally 
 require conversion between each other. It's busywork without a 
 justification.


They're not strictly the same. Consider the following function 
calls:

foo(1, 2, 3)
foo((1, 2, 3))
foo((1, 2), 3)
foo(1, (2, 3))
foo((1), (2), (3))
etc.

Maybe you intend for tuples to automatically "flatten" in the 
context of a function argument list (that is, all of the above 
expressions would be equal to foo(1, 2, 3)). This is a valid 
design decision but notably this is very different from how array 
and struct literals work. If the signature of foo were

void foo(int[2], int[1]);

then foo([1,2],[3]) is accepted, but foo([1],[2, 3]) is rejected. 
This is the kind of "implicit casting" I'm talking about.
May 10 2020
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 10.05.20 22:59, Mark wrote:

 On Sunday, 10 May 2020 at 17:56:22 UTC, Timon Gehr wrote:

 On 10.05.20 14:06, Mark wrote:

 On Sunday, 10 May 2020 at 03:14:08 UTC, Timon Gehr wrote:

 On 09.05.20 19:07, Mark wrote:

 but the syntax is extremely terse (*mytuple).


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




 print(list(map(lambda t: foo(*t), [(1, 2), (3, 4)])))


 Hmmm, very good point.

 The issue seems similar (at least in spirit) to that of implicit 
 casting. Implicit casting is, in a sense, syntactic sugar, saving you 
 from writing "cast(mytype) myval" all over the place. It's also a 
 highly contentious issue; everyone seems to be have their opinion of 
 the extent to which implicit casting is a good thing.


 It's not really similar. The problem is that there are two different 
 things that are actually the same but still formally require 
 conversion between each other. It's busywork without a justification.


 
 They're not strictly the same. Consider the following function calls:
 
 foo(1, 2, 3)
 foo((1, 2, 3))
 foo((1, 2), 3)
 foo(1, (2, 3))
 foo((1), (2), (3))
 etc.
 
 Maybe you intend for tuples to automatically "flatten" in the context of 
 a function argument list (that is, all of the above expressions would be 
 equal to foo(1, 2, 3)).


No, that would be terrible.


 This is a valid design decision but notably this 
 is very different from how array and struct literals work. If the 
 signature of foo were
 
 void foo(int[2], int[1]);
 
 then foo([1,2],[3]) is accepted, but foo([1],[2, 3]) is rejected. This 
 is the kind of "implicit casting" I'm talking about.


Well, I think this is a bad idea and I did not suggest it.
May 10 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/8/2020 1:38 PM, 12345swordy wrote:

 As I am working on the "Tuples first class feature" dip


Keep in mind that as of recently, AliasSeq!(1,2,3) generates a tuple directly 
without going through the template instantiation mechanism.
May 08 2020
next sibling parent reply Manu <turkeyman gmail.com> writes:
On Sat, May 9, 2020 at 1:05 PM Walter Bright via Digitalmars-d <
digitalmars-d puremagic.com> wrote:


 On 5/8/2020 1:38 PM, 12345swordy wrote:

 As I am working on the "Tuples first class feature" dip


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


It's still hideous though. Fundamental language features would ideally be
acknowledged and speced rather than expressed incidentally by an ugly hack.
May 08 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
May 08 2020
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 09.05.20 06:41, Walter Bright 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.


It is not a viable alternative, which the DIP might discuss, but I don't 
really see why it has to. For example, you cannot create a range of 
AliasSeq's, which should make it obvious that it does not fulfill the 
desired role. Auto-expansion is nice as a feature and having 
auto-expanding sequences actually be first-class objects is a nice 
touch, but they don't replace traditional tuples.
May 08 2020
prev sibling parent reply Manu <turkeyman gmail.com> writes:
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.
May 09 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
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}.
May 09 2020
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
May 08 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
May 08 2020
prev sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Saturday, 9 May 2020 at 03:04:45 UTC, 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.


Nice. I still think a builtin syntax including pattern matching 
is needed, though.
May 10 2020