On Thursday, 20 September 2012 at 21:04:15 UTC, Timon Gehr wrote:
> On 09/20/2012 10:52 PM, Peter Alexander wrote:
>> 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.

Conciseness encourages use, both wise and unwise.

I don't think that templates should have more concise syntax than non-templates. Having shorter syntax suggests that it should be the default choice, and it's a bad default choice for most functions.

> 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?

I don't see any way the proposed syntax could work either. We could have this, though:

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

But I don't think this feature is worth changing the language anyway.

On Friday, 21 September 2012 at 11:40:54 UTC, Jonathan M Davis wrote:
> 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.

Correct. The same with foreach where you also just save some characters but it is darn nice anyway.

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

Fair enough.

-Jonas

On Friday, 21 September 2012 at 15:04:14 UTC, Steven Schveighoffer wrote:
> 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) {}

This would not be a valid syntax in my proposal since x is not a parameter name as it should be, but a type name.

> 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?

A mentioned in the proposal (albeit not very clear) it requires non-templated function definitions to include both type and param names. If only one name is provided in a definition is always a param name. Unfortunately this is a breaking change for some code and that does speak against the proposal.

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

I agree.

On 2012-09-21, 21:29, Jonas Drewsen wrote:

> A mentioned in the proposal (albeit not very clear) it requires non-templated function definitions to include both type and param names. If only one name is provided in a definition is always a param name. Unfortunately this is a breaking change for some code and that does speak against the proposal.

Not only is it a breaking change, it breaks one of the basic design
desiderata of D - if it's valid C it either fails to compile or compiles
with the same behavior as in C.

-- 
Simen

On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas wrote:
> On 2012-09-21, 21:29, Jonas Drewsen wrote:
>
>> A mentioned in the proposal (albeit not very clear) it requires non-templated function definitions to include both type and param names. If only one name is provided in a definition is always a param name. Unfortunately this is a breaking change for some code and that does speak against the proposal.
>
> Not only is it a breaking change, it breaks one of the basic design
> desiderata of D - if it's valid C it either fails to compile or compiles
> with the same behavior as in C.

I guess it is not that basic of a desiderata after all :)

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

-Jonas

On Monday, September 24, 2012 10:37:04 Jonas Drewsen wrote:
> On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas
> 
> wrote:
> > On 2012-09-21, 21:29, Jonas Drewsen wrote:
> >> A mentioned in the proposal (albeit not very clear) it requires non-templated function definitions to include both type and param names. If only one name is provided in a definition is always a param name. Unfortunately this is a breaking change for some code and that does speak against the proposal.
> > 
> > Not only is it a breaking change, it breaks one of the basic
> > design
> > desiderata of D - if it's valid C it either fails to compile or
> > compiles
> > with the same behavior as in C.
> 
> I guess it is not that basic of a desiderata after all :)
> 
> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19

It has been broken upon rare occasion (e.g. static arrays are value types in D, not reference types like in C), but it's quite rare, and removing the comera operator doesn't necessarily break it. In fact, just removing the comma operator _definitely_ doesn't break it, because it just makes more C code invalid. The point is that C/C++ will compile as valid D code with the same semantics or that it won't compile, _not_ that C/C++ will compile as valid D code. The whole point is to avoid silent behavioral changes when porting C/C++ code to D.

Now, that being said, if tuples are added to the language proper (which that DIP doesn't do), that may or may not make it so that C/C++ code will end up compiling with different semantics when ported. I'd have to study the situation much more closely to be sure, but I suspect that it wouldn't, precisely because the types involved change and C doesn't have auto in the same way that D does (or any kind of type inferrence at all really), so the change in type would cause compilation failure, thereby avoiding silent behavioral changes.

- Jonathan M Davis

On Monday, 24 September 2012 at 10:05:49 UTC, Jonathan M Davis wrote:
> On Monday, September 24, 2012 10:37:04 Jonas Drewsen wrote:
>> On Saturday, 22 September 2012 at 07:48:14 UTC, Simen Kjaeraas
>> 
>> wrote:
>> > On 2012-09-21, 21:29, Jonas Drewsen wrote:
>> >> A mentioned in the proposal (albeit not very clear) it
>> >> requires non-templated function definitions to include both
>> >> type and param names. If only one name is provided in a
>> >> definition is always a param name. Unfortunately this is a
>> >> breaking change for some code and that does speak against the
>> >> proposal.
>> > 
>> > Not only is it a breaking change, it breaks one of the basic
>> > design
>> > desiderata of D - if it's valid C it either fails to compile or
>> > compiles
>> > with the same behavior as in C.
>> 
>> I guess it is not that basic of a desiderata after all :)
>> 
>> http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel/DIPs/DIP19
>
> It has been broken upon rare occasion (e.g. static arrays are value types in
> D, not reference types like in C), but it's quite rare, and removing the
> comera operator doesn't necessarily break it. In fact, just removing the comma
> operator _definitely_ doesn't break it, because it just makes more C code
> invalid. The point is that C/C++ will compile as valid D code with the same
> semantics or that it won't compile, _not_ that C/C++ will compile as valid D
> code. The whole point is to avoid silent behavioral changes when porting C/C++
> code to D.
>
> Now, that being said, if tuples are added to the language proper (which that
> DIP doesn't do), that may or may not make it so that C/C++ code will end up
> compiling with different semantics when ported. I'd have to study the situation
> much more closely to be sure, but I suspect that it wouldn't, precisely
> because the types involved change and C doesn't have auto in the same way that
> D does (or any kind of type inferrence at all really), so the change in type
> would cause compilation failure, thereby avoiding silent behavioral changes.
>
> - Jonathan M Davis

What about:

int fun() {
    return (0, "abc")[0];
}

in the comma operator case it would return 'a' as an int.
in the tuple case it would return 0

/Jonas

On Monday, September 24, 2012 19:18:09 Jonas Drewsen wrote:
> What about:
> 
> int fun() {
> return (0, "abc")[0];
> }
> 
> in the comma operator case it would return 'a' as an int. in the tuple case it would return 0

Like I said, I'd have to examine the situation more closely to be certain that there are no places where C code would compile but change semantics. It looks like you found one. That may or may not be enough to make it so that tuples wouldn't be done that way. On rare occasions, C compatability has been broken in this regard, but it's very rare. So, it's a very strong rule, but it's not unbreakable.

Also, it's already been suggested in the thread on DIP 19 that we just give different syntax to tuples to fix the problem. And it's not at all clear that there's agreement that adding tuples to the language buys enough to make it worth it anyway. So, who knows what will happen.

- Jonathan M Davis