In foreach statements the type can be inferred:

foreach (MyFooBar fooBar; fooBars) writeln(fooBar);
same as:
foreach (foobar; fooBars) writeln(fooBar);

This is nice and tidy.
Wouldn't it make sense to allow the same for function templates as well:

auto min(L,R)(L a, R b)
{
    return a < b;
}

same as:

auto min(a,b)
{
    return a < b;
}

What am I missing (except some code that needs chaging because only param type and not name has been specified in t?

/Jonas

On Thursday, 20 September 2012 at 19:56:48 UTC, Jonas Drewsen wrote:
> In foreach statements the type can be inferred:
>

Clicked the send butten too early by mistake but I guess you get the idea.

/Jonas

On Thursday, 20 September 2012 at 19:56:48 UTC, Jonas Drewsen wrote:
> Wouldn't it make sense to allow the same for function templates as well: <snip>
>
> What am I missing (except some code that needs chaging because only param type and not name has been specified in t?

I can't see any implementation issues with it, but I think templates should be an explicit choice when writing functions.

Like it or not, templates still cause a lot of code bloat, complicate linking, cannot be virtual, increase compilation resources, and generate difficult to understand messages. They are a powerful tool, but need to be used wisely.

On 09/20/2012 09:57 PM, Jonas Drewsen wrote:
> ...
> What am I missing (except some code that needs chaging because only
> param type and not name has been specified in [i]t?
>

Nothing, that is about it. (C backwards-compatibility could maybe be
added) Of course, we could make upper case identifiers indicate
parameters without name and lower case identifiers indicate parameters
with templated types, keeping the breakages at a minimum. :o)

Note that other language changes would have to be made, eg:

void main(){
    int delegate(int) dg1 = x=>x; // currently ok, should stay ok
    auto foo(T)(T x){ return x; }
    int delegate(int) dg2 = &foo; // currently error, would become ok
}

(x=>x would become a template delegate literal following your proposal)

On 09/20/2012 10:52 PM, Peter Alexander wrote:
> On Thursday, 20 September 2012 at 19:56:48 UTC, Jonas Drewsen wrote:
>> Wouldn't it make sense to allow the same for function templates as
>> well: <snip>
>>
>> What am I missing (except some code that needs chaging because only
>> param type and not name has been specified in t?
>
> I can't see any implementation issues with it, but I think templates
> should be an explicit choice when writing functions.
>

Leaving out the parameter type is an explicit choice.

> Like it or not, templates still cause a lot of code bloat, complicate
> linking, cannot be virtual, increase compilation resources, and generate
> difficult to understand messages. They are a powerful tool, but need to
> be used wisely.
>

The proposal does not make wise usage harder. It only makes usage more
concise in some cases.

On Thursday, September 20, 2012 21:57:47 Jonas Drewsen wrote:
> In foreach statements the type can be inferred:
> 
> foreach (MyFooBar fooBar; fooBars) writeln(fooBar);
> same as:
> foreach (foobar; fooBars) writeln(fooBar);
> 
> This is nice and tidy.
> Wouldn't it make sense to allow the same for function templates
> as well:
> 
> auto min(L,R)(L a, R b)
> {
> return a < b;
> }
> 
> same as:
> 
> auto min(a,b)
> {
> return a < b;
> }
> 
> What am I missing (except some code that needs chaging because only param type and not name has been specified in t?

You don't want everything templated. Templated functions are fundamentally different. They don't exist until they're instantiated, and they're only instantiated because you call them. Sometimes, you want functions to always exist regardless of whether any of your code is calling them (particularly when dealing with libraries).

Another result of all of this is that templated functions can't be virtual, so your proposal would be a _huge_ problem for classes. Not to mention, errors with templated functions tend to be much nastier than with non-templated functions even if it's not as bad as C++. Also, your prosposal then means that we'd up with templated functions without template constraints as a pretty normal thing, which would mean that such functions would frequently get called with types that don't work with them. To fix that, you'd have to add template constraints to such functions, which would be even more verbose than just giving the types like we do now.

You really need to be able to control when something is templated or not. And your proposal is basically just a terser template syntax. Is it really all that more verbose to do

auto min(L, R)(L a, R b) {...}

rather than

auto min(a, b) {...}

And even if we added your syntax, we'd still need the current syntax, because you need to able to indicate which types go with which parameters even if it's just to say that two parameters have the same type.

Also, what happens if you put types on some parameters but not others? Are those parameters given templated types? If so, a simple type could silently turn your function into a templated function without you realizing it.

Then there's function overloading. If you wanted to overload a function in your proposal, you'd have to either still give the types or use template constraints, meaning that it can't be used with overloaded functions.

Another thing to consider is that in languages like Haskell where all parameter types are inferred, it's often considered good practice to give the types anyway (assuming that the language lets you - Haskell does), because the functions are then not only easier to understand, but the error messages are more sane.

So, I really don't think that this is a good idea. It's just a terser, less flexible, and more error-prone syntax for templates.

- Jonathan M Davis

On Thursday, 20 September 2012 at 21:39:31 UTC, Jonathan M Davis wrote:
> On Thursday, September 20, 2012 21:57:47 Jonas Drewsen wrote:
>> In foreach statements the type can be inferred:
>> 
>> foreach (MyFooBar fooBar; fooBars) writeln(fooBar);
>> same as:
>> foreach (foobar; fooBars) writeln(fooBar);
>> 
>> This is nice and tidy.
>> Wouldn't it make sense to allow the same for function templates
>> as well:
>> 
>> auto min(L,R)(L a, R b)
>> {
>> return a < b;
>> }
>> 
>> same as:
>> 
>> auto min(a,b)
>> {
>> return a < b;
>> }
>> 
>> What am I missing (except some code that needs chaging because
>> only param type and not name has been specified in t?
>
> You don't want everything templated. Templated functions are fundamentally
> different. They don't exist until they're instantiated, and they're only
> instantiated because you call them. Sometimes, you want functions to always
> exist regardless of whether any of your code is calling them (particularly
> when dealing with libraries).

I agree. And in that case just use a non-templated version that specifies the types as always.

> Another result of all of this is that templated functions can't be virtual, so
> your proposal would be a _huge_ problem for classes. Not to mention, errors
> with templated functions tend to be much nastier than with non-templated
> functions even if it's not as bad as C++.

I don't see how the terser syntax for templated functions has anything to do with this. The things you mention are simply facts about templated functions and nothing special for the suggested syntax.

> Also, your prosposal then means that
> we'd up with templated functions without template constraints as a pretty
> normal thing, which would mean that such functions would frequently get called
> with types that don't work with them. To fix that, you'd have to add template
> constraints to such functions, which would be even more verbose than just
> giving the types like we do now.

By looking at the two examples I provided, both the existing syntax and the new one suffers from that. The new one is just nicer on the eyes I think.

> You really need to be able to control when something is templated or not. And
> your proposal is basically just a terser template syntax. Is it really all
> that more verbose to do
>
> auto min(L, R)(L a, R b) {...}
>
> rather than
>
> auto min(a, b) {...}

Some people would love to be able to use D as a scripting language using e.g. rdmd. This is the kind of thing that would make it very attractive for scripting.

I am _not_ suggesting to replace the existing syntax since that really should be used for things like phobos where everything must be checked by the type system as much as possible upfront. But for many programs (especially in the prototyping/exploratory phases) the same kind of thoroughness is not within the resource limits.

That is probably why many use dynamically typed languages like python/ruby for prototyping and first editions and end up sticking with those languages in the end. D has already taken great steps in that direction and this is just a suggestion to make it even more attractive.

> And even if we added your syntax, we'd still need the current syntax, because
> you need to able to indicate which types go with which parameters even if it's
> just to say that two parameters have the same type.

As mentioned before this suggestion is an addition. Not a replacement.

> Also, what happens if you put types on some parameters but not others? Are
> those parameters given templated types? If so, a simple type could silently
> turn your function into a templated function without you realizing it.

Maybe I wasn't clear in my suggestion. The new syntax in simply a way to define a templated function - not a non-templated one ie:

auto foo(a,b) {}
is exactly the same as
auto foo(A,B)(A a, B b) {}

The semantic of what should happen if one of the parameters had its type provided is up for discussion. But I think that it should be allowed and just lock that template parameter to that type. This would not change it from templated to non-templated in any case afaik.

> Then there's function overloading. If you wanted to overload a function in
> your proposal, you'd have to either still give the types or use template
> constraints, meaning that it can't be used with overloaded functions.

Yes. As with the the existing template syntax.

> Another thing to consider is that in languages like Haskell where all
> parameter types are inferred, it's often considered good practice to give the
> types anyway (assuming that the language lets you - Haskell does), because the
> functions are then not only easier to understand, but the error messages are
> more sane.

And the good practice is done on stable code or when you are sure about what you are doing from the start. I do not think it is uncommon to try out a solution and refactor and iterate until things gets nice and tidy. This is definitely not the only way to work, but for some problem domains (especially the ones you are not well versed in yet) this is not uncommon. That claim is my own :)

I guess "productivity" could be a buzz word to put in here  if I were into buzzwords.

/Jonas

I'll add that delegate literals already allow a similar syntax, so, for consistency reasons, this is something that make sense.

On Friday, September 21, 2012 13:14:56 Jonas Drewsen wrote:
> Maybe I wasn't clear in my suggestion. The new syntax in simply a way to define a templated function - not a non-templated one ie:
> 
> auto foo(a,b) {}
> is exactly the same as
> auto foo(A,B)(A a, B b) {}

So all it does is save you a few characters? I don't think that that's even vaguely worth it. It complicates the language and doesn't add any functionality whatsoever.

And when you consider that it then makes it _harder_ to quickly see that a function is templated, and it potentially makes it easier to accidentally templatize a function, I think that it's a net loss even without considering the fact that it complicates the language further. And _with_ considering it, I think that it's definitely more trouble than it's worth.

- Jonathan M Davis

On Thu, 20 Sep 2012 15:57:47 -0400, Jonas Drewsen <jdrewsen@nospam.com> wrote:

> In foreach statements the type can be inferred:
>
> foreach (MyFooBar fooBar; fooBars) writeln(fooBar);
> same as:
> foreach (foobar; fooBars) writeln(fooBar);
>
> This is nice and tidy.
> Wouldn't it make sense to allow the same for function templates as well:
>
> auto min(L,R)(L a, R b)
> {
>      return a < b;
> }
>
> same as:
>
> auto min(a,b)
> {
>      return a < b;
> }
>
> What am I missing (except some code that needs chaging because only param type and not name has been specified in t?

Although I like it, I wonder if it works in D's context free grammar.  Timon probably would know best...

I came up with this code, which compiles today:

import std.stdio;
alias int x;

void foo(x) {}

void foo2(string x) {writeln(x);}

void main()
{
    foo(1);
    foo2("hello");
}

Under your proposal, if we shorten foo2 to foo2(x), what happens?  Does it become just like foo?  Or does it turn into a template?  Or is it an error?

Note that just because some syntax isn't valid doesn't mean it should be utilized for a valid use.  That can result in code compiling and meaning something completely different than you expect.

-Steve