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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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