On Friday, 27 January 2017 at 19:32:29 UTC, Jesse Phillips 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.
>
> 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:
>

The type is deduced from the function call. There is no need to specify it or specify new. This is why the syntax reduces the complexity(of course, at the cost of increase terseness) and lines.


e.g., for your foo to be valid, it must have a declaration of foo(T1,T2,T3).

So why should we have to specify that when the compiler can do it for us?

The special syntax informs the compiler that we are initializing the types with the given arguments and it simply rewrites it in the long hand form.

It can only be used when the type can be deduced.

On Friday, 27 January 2017 at 12:44:30 UTC, rjframe wrote:
> 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.
>

I can only argue on the merit when the criticism is of the actual problem, not of unrelated assumptions.

e.g., How can you or Bauss argue against what I have said when I haven't said much. In fact, since Bauss was against it without even really hearing or understanding it(the syntax, since that is what he said he was against), and C99 already implements such a thing, it proves my point that he is just being a nay-Sayer. It's good enough for the c99 committee but not him?

You are following in his shoes though. Instead of arguing on the actual concept proposed you are creating noise. All I can say, is take your own advice.


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

Criticism must come from reason, not fear.

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

Yes, but you haven't said anything about the original concept. The above is obvious. Life is full of constraints in everything. You could say the same about banking, bout sex, about building a bridge, etc.

On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter wrote:
> On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis 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.


Yeah, this seems similar to what I am saying. The only difference is that the cast is not required because the types can be deduced for functions. I don't see anything in the spec(https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Compound-Literals.html) showing function calls using "compound literals though", which was my suggestion.

On Saturday, 28 January 2017 at 01:55:10 UTC, Profile Anaysis wrote:
> On Friday, 27 January 2017 at 11:16:09 UTC, Patrick Schluter wrote:
>> On Thursday, 26 January 2017 at 00:02:03 UTC, Profile Anaysis 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.
>
>
> Yeah, this seems similar to what I am saying. The only difference is that the cast is not required because the types can be deduced for functions. I don't see anything in the spec(https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Compound-Literals.html) showing function calls using "compound literals though", which was my suggestion.

The typecast in the compound statement is required because the initializer expression is ambiguous because of int promotion rules

struct aa { short a; char c; } and struct bb { int a; int b} have exactly the same initializer but are completely different types.
 { 5, 41 } applies to both without problem. In C the cast is required so that the compiler can generate the anonymous object (object in th C standard sense) in the right type. When the initialiser is used in an variable definition context then the type is deduced from the definition itself (no auto type deduction in C, so the type can be deduced).
In D the compound syntax doesn't exist, but it is not required, because there is already a syntax for something very similar. The type must be given explicitly for the same reason as in C as D follows the same integer promotion rules.
Furthermore, in the context of a function call (which is only a subpart of the more general creating/initialising of objects) D adds a difficulty that C doesn't : overloads. Imagine a function
f with 2 overloads void f(struct aa); and void f(struct bb);  which one will be called if we use f({5, 41}); ? (pseudo syntax)
Templates take that issue to another level because there you don't even see explicitely the overloads, they are generated automagically by the compiler.

Conclusion: a new syntax is not necessary as the current way of doing things is already minimal.