www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A better way to deal with overloading?

reply Profile Anaysis <PA gotacha.com> writes:
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.
Jan 25 2017
next sibling parent reply Bauss <jj_1337 live.dk> writes:
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.
Jan 27 2017
next sibling parent ixid <adamsibson protonmail.com> writes:
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?
Jan 27 2017
prev sibling parent reply Profile Anaysis <PA gotacha.com> writes:
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)].
Jan 27 2017
parent reply rjframe <dlang ryanjframe.com> writes:
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).
Jan 27 2017
parent Profile Anaysis <PA gotacha.com> writes:
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.
Jan 27 2017
prev sibling next sibling parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Jan 27 2017
next sibling parent reply Kagamin <spam here.lot> writes:
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.
Jan 27 2017
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Jan 27 2017
prev sibling parent reply Profile Anaysis <PA gotacha.com> writes:
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.
Jan 27 2017
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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.
Jan 27 2017
prev sibling next sibling parent Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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.
Jan 27 2017
prev sibling parent reply Jesse Phillips <Jesse.K.Phillips+D gmail.com> writes:
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.
Jan 27 2017
parent Profile Anaysis <PA gotacha.com> writes:
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.
Jan 27 2017