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

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

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

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

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)

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.

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.

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.

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.

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.