Many times we pass compound types(non-primitives) as arguments to functions.

e.g.,

    void foo(T1 t1, T2 t2, T3, t3);

But to call foo with new variables we have to create the arguments. This usually requires extra code to simply initialize the variables. (imagine foo being a constructor).

It may be better to use a recursive process where we can specify all the values of the arguments inline.

e.g.,

    foo(|a,b,c|,|e|,|f,g,c|).

(I am using | but any type of symbolic notation could be used)

would be equivalent to

foo(T1(a,b,c),T2(e),T3(f,g,c)).

When the T's are structs(other wise maybe new, or we can imply new for classes to make it uniform).


If T1 has a compound type for the 3rd parameter, we can then call it like

    foo(|a,b,|c1,c2,3||,|e|,|f,g,c|).

this avoids having to do things like

auto t1 = T1(a,b,new X(c1,c2,c3));
auto t2 = T2(e);
auto t3 = T3(f,g,c);

and then f(t1,t2,t3);

or other wise simply inline the above.


This also cuts down on constructor overloading.

This is sort of liked named parameters but the idea is that the compiler simply constructs the type internally as it knows what type to expect and the grouping symbols allow one to specify the contents unambiguously.

On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote:
> Many times we pass compound types(non-primitives) as arguments to functions.
>
> [...]

This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me.

On Friday, 27 January 2017 at 09:47:48 UTC, Bauss wrote:
> On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote:
>> Many times we pass compound types(non-primitives) as arguments to functions.
>>
>> [...]
>
> This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me.

Out of interest what syntactic sugar would you remove?

On Friday, 27 January 2017 at 09:47:48 UTC, Bauss wrote:
> On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote:
>> Many times we pass compound types(non-primitives) as arguments to functions.
>>
>> [...]
>
> This is going to be a no from me. It's just another syntactic sugar that doesn't really have a purpose, but more syntactic confusion. We have enough of that stuff in D if you ask me.

Do you realize

1. That without change there can be no progress?

2. Everything is syntactic sugar. The only way to increase efficiency is to create higher level abstractions.

If people with your mentality rules the world we would still be using sticks and stones. This is a fact... I won't argue whether it would be the best thing or not.

At any point in the progress of humans people can say and do say what effectively what you are saying.

Without people ignoring you and pushing the boundaries humanity would not be where it is at.

e.g., "I disagree, punch cards are all we need.". "Tubes can do anything. There is no use in trying to control them with automation, we have hands for that". "The stone wheel has served us for centuries, it has proven reliability. There is no need to try to make it better".

Because you think such a syntax(one that hasn't even been created yet) will somehow be detrimental to your progress is insanity.

1. You have no way to judge the syntax since it hasn't been created yet. Hence you have to be against all syntactic sugar, which I already pointed out, is everything. Hence you are actually against progress in the big picture, including your own.

2. You are not forced to use syntax extensions. If you are able to continue doing exactly what you did before there should be no need to be against it. It's like saying you are against cars because you want to walk. Well, no one is stopping you from walking by them having a car.

[Your only argument is that the syntax(e.g., the car) is detrimental to you in some innate way that it's mere existence forces you to be have in an undesirable way. This isn't an argument though as I could use the reverse for my side. (e.g., I need a car to do things I need to do)].

On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote:
> Many times we pass compound types(non-primitives) as arguments to functions.
>
> e.g.,
>
>     void foo(T1 t1, T2 t2, T3, t3);
>
> But to call foo with new variables we have to create the arguments. This usually requires extra code to simply initialize the variables. (imagine foo being a constructor).
>
> It may be better to use a recursive process where we can specify all the values of the arguments inline.
>
> e.g.,
>
>     foo(|a,b,c|,|e|,|f,g,c|).
>
> (I am using | but any type of symbolic notation could be used)
>
> would be equivalent to
>
> foo(T1(a,b,c),T2(e),T3(f,g,c)).
>
> When the T's are structs(other wise maybe new, or we can imply new for classes to make it uniform).
>
>
> If T1 has a compound type for the 3rd parameter, we can then call it like
>
>     foo(|a,b,|c1,c2,3||,|e|,|f,g,c|).
>
> this avoids having to do things like
>
> auto t1 = T1(a,b,new X(c1,c2,c3));
> auto t2 = T2(e);
> auto t3 = T3(f,g,c);
>
> and then f(t1,t2,t3);
>
> or other wise simply inline the above.
>
>
> This also cuts down on constructor overloading.
>
> This is sort of liked named parameters but the idea is that the compiler simply constructs the type internally as it knows what type to expect and the grouping symbols allow one to specify the contents unambiguously.

It's funny (or sad) that C has compound types since C99 and that they are good.
Your  foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as

foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});

of course, the lack of object orientation and other things makes it easier in C.

On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote:
> auto t1 = T1(a,b,new X(c1,c2,c3));
> auto t2 = T2(e);
> auto t3 = T3(f,g,c);
>
> and then f(t1,t2,t3);
>
> or other wise simply inline the above.
>
>
> This also cuts down on constructor overloading.
>
> This is sort of liked named parameters but the idea is that the compiler simply constructs the type internally as it knows what type to expect and the grouping symbols allow one to specify the contents unambiguously.
You can init structs, and classes inside the function call. Ex:
import std.stdio;

struct T1 {
    int a;
    int b;
    int c;
}

struct T2 {
    int b;
    string a;
    T1 t;
}

class T3 {
    int z;
    int m;

    this(int z, int m) {
        this.z = z;
        this.m = m;
    }
}

void foo(T1, T2, T3) {

}
void main() {

    foo(
        T1(1, 2, 3), // arguments are passed as rvalues to func.
        T2(2, "tested",T1(1, 2, 3)), // compound struct
        new T3(10, 20)
    );
}

If new is not desired to be in your code, it's possible to use opCall overload to mimic structs initialization, for classes.

Alexandru.

On Fri, 27 Jan 2017 10:38:53 +0000, Profile Anaysis wrote:

> Do you realize
> 
> 1. That without change there can be no progress?
> 
> ...
> If people with your mentality rules the world we would still be using
> sticks and stones. This is a fact... I won't argue whether it would be
> the best thing or not.

Please argue for your proposal on its merit, not by criticizing the people who disagree. It can be difficult to communicate/work with strangers -- all we have is respect and the benefit of the doubt, and cannot afford to lose either.

You'd have a much better chance of getting a language change by a) getting a couple of people who agree with you to write a quality DIP, and b) listening to the criticism of those who disagree to refine the proposal (or in this specific case, find that it's not necessary (Alexandru Ermicioi's code)).

> Because you think such a syntax(one that hasn't even been created yet) will somehow be detrimental to your progress is insanity.
> 
> 1. You have no way to judge the syntax since it hasn't been created yet. Hence you have to be against all syntactic sugar, which I already pointed out, is everything. Hence you are actually against progress in the big picture, including your own.

A language is more than its feature set; language design is about balancing features and constraints. A language that tries to let you do anything and everything would make it too easy to create an unmaintainable mess (e.g., we need constraints either in the language or in the programmer).

On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter wrote:
> It's funny (or sad) that C has compound types since C99 and that they are good.
> Your  foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
>
> foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
>
> of course, the lack of object orientation and other things makes it easier in C.

It's struct literals, a gcc extension, not in language.

On Friday, 27 January 2017 at 12:59:54 UTC, Kagamin wrote:
> On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter wrote:
>> It's funny (or sad) that C has compound types since C99 and that they are good.
>> Your  foo(|a,b,|c1,c2,3||,|e|,|f,g,c|) writes as
>>
>> foo((T1){a,b,{c1,c2,c3}}, (T2){e}, (T3){f,g,c});
>>
>> of course, the lack of object orientation and other things makes it easier in C.
>
> It's struct literals, a gcc extension, not in language.

No, they're named compound* literals and they are in the language since C99.

https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Compound-Literals.html

* They can be used to initialise also unions and arrays. (int [10]){0,2,[8]=2} is absolutely legal p.ex.

On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis wrote:
> Many times we pass compound types(non-primitives) as arguments to functions.

I don't understand what issue you are solving. I see an undefined syntax:

foo(|a,b,|c1,c2,3||,|e|,|f,g,c|)

To replace an existing syntax:

foo(T1(a,b,new X(c1,c2,c3)),T2(e),T3(f,g,c));

The primary difference I'm seeing is that the undefined syntax doesn't specify what type is being created. To this end the one time I recall desiring this is when using std.variant:

void foo(Variant v) { ... }

'foo' will now take anything, but I can't call it with anything, instead I must call:

foo(Variant(3));

or

foo(Algebraic!(int, string, float)("hello"))

But this is a very special type.