TODAY:
public int add(int a, int b, int c)
{
return a + b + c;
}
WANT:
public int add(int: a, b, c) // a, b, and c are all int.
{
return a + b + c;
}
SYNTAX:
scope return_type function_name(type1: arg1, arg2, arg3, type2: arg4, arg5, type3 arg6)
{
//body
}
All arguments following a colon type are of that type, until another type is encountered.
e.g.
public string kidPlayed(int: hours, minutes, string name,int goals)
{
return String.Format("{0} played for {1}:{2} and scored {3} goals",name,hours,minutes,goals);
}
We already have a similar syntax WRT automatics.
{
int a,b,c;
:
}
Perhaps, to be consistant with the automatic syntax, nix the colon.
public int add(int a,b,c)
{
return a + b + c;
}
I think that this would conflict with the existing syntax of argument parameters, with the comma being used to indicate the separation of parameters. An alternative syntax based on your concept is to use space as argument name separation in the "copycat" parameter.
int: arg0 arg1 arg2, string: arg3 arg4
rough grammar
parameter ::= attributes typeIdentifer (standard | copycat ) optionalValue?
required ::= ws+ parameterName
copycat ::= colon ws+ parameterName+
optional ::= ws* equals ws* constantExpr
@codecore I understand the need for making things as terse as possible, when possible but I dislike it simply because it seems like you trade readability with having a terser code for _no_ benefit.
If I have to pick between this version:
public string foo(int arg0, arg1, string arg2, int arg3)
{
}
And the following version:
public string foo(int arg0, int arg1, string arg2, int arg3)
{
}
I think that the latter version is more readable.
However, in the following case where all of the arguments are of the same type then you get to have a pretty succinct and readable code without hindered readability so I'm all for it.
public int foo(int arg0, arg1, arg2, arg3)
{
}
I prefer no colon:
c#
void Foo(int a, b, string c) { }
Then it's a simple change, each argument without a type assumes the previous argument's type.
How would this work for ref and out?
c#
void Bar(out int x, y) { ... }
Would y also be out?
@bondsbw In the alteration I've suggested it would be. All attributes would be "copied" over.
Let's take one of your examples:
public string kidPlayed(int hours, int minutes, string name, int goals)
{
return String.Format("{0} played for {1}:{2} and scored {3} goals",name,hours,minutes,goals);
}
Now, we _could_ support making it terser using this suggestion:
public string kidPlayed(int: hours, minutes, string name,int goals)
{
return String.Format("{0} played for {1}:{2} and scored {3} goals",name,hours,minutes,goals);
}
Or we could - using existing syntax - make it easier to read:
public string kidPlayed(int hours, int minutes, string name, int goals) =>
$"{name} played for {hours}:{minutes} and scored {goals} goals";
Like @eyalsk, I don't think that dropping the type definitions makes the code easier to read and don't see that his single type example is enough of a win to justify the cost of the change.
@DavidArno Using my variant of this proposal.
``` c#
public string kidPlayed(int: hours minutes, string name, int goals) =>
$"{name} played for {hours}:{minutes} and scored {goals} goals";
One from the type `String`
``` c#
[CLSCompliant(false)]
public static String Concat(Object: arg0 arg1 arg2 arg3, __arglist)
Well, if we are on that road, we are pretty close to:
public static Func<int,int,string,int,string> kidPlayed = (hours,minutes,name,goals) =>
$"{name} played for {hours}:{minutes} and scored {goals} goals";
Not really where I was going with this. I suspect that the cost of the proposal is minimal. Probably just a simple scan with an updatable current-type, emitting the current type with each argument name.
Most helpful comment
Let's take one of your examples:
Now, we _could_ support making it terser using this suggestion:
Or we could - using existing syntax - make it easier to read:
Like @eyalsk, I don't think that dropping the type definitions makes the code easier to read and don't see that his single type example is enough of a win to justify the cost of the change.