I just thought of something:

The patterns

	auto foo1(T)(T arg) { /+ ... +/ }
	auto foo2(T...)(T args) { /+ ... +/ }

are very common.


Why not just supporting the syntax

	auto foo1(auto arg) { /+ ... +/ }
	auto foo2(auto args...) { /+ ... +/ }

to make things easier?

People can still say typeof(arg), typeof(args[0]), etc., just like
before, but it's a lot easier (and cooler!) to have a code with all
inferred types, rather than explicitly typed templates.

Any ideas?

On 2011-06-02 20:16, Mehrdad wrote:
> I just thought of something:
> 
> The patterns
> 
> 	auto foo1(T)(T arg) { /+ ... +/ }
> 	auto foo2(T...)(T args) { /+ ... +/ }
> 
> are very common.
> 
> 
> Why not just supporting the syntax
> 
> 	auto foo1(auto arg) { /+ ... +/ }
> 	auto foo2(auto args...) { /+ ... +/ }
> 
> to make things easier?
> 
> People can still say typeof(arg), typeof(args[0]), etc., just like
> before, but it's a lot easier (and cooler!) to have a code with all
> inferred types, rather than explicitly typed templates.
> 
> Any ideas?

And what benefit would that really be? Using auto like that would have to be converted to a template anyway. It's not like a function can magically take any type for a parameter. The type must be known. Templates do that by generating a new version of the function for every new set of template parameters. auto couldn't do it without being turned into a template. And then you're just covering up the template syntax with some potentially confusing syntactic sugar. You wouldn't have any template constraints, which would mean that the error messages would be horrible. You _can't_ explicitly instantiate the template anymore if you need to, and it doesn't give you any more type inference than you do with templates. It's not even any less typing! In fact, it's exactly the same number of characters. All such a feature would do would be to hide the fact that templates were being used, and since you need to understand templates to use D properly - especially when dealing with Phobos - that doesn't help at all.

I see no advantages with this idea and quite a few disadvantages. This proposal adds absolutely nothing.

- Jonathan M Davis

== Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
> On 2011-06-02 20:16, Mehrdad wrote:
> > I just thought of something:
> >
> > The patterns
> >
> > 	auto foo1(T)(T arg) { /+ ... +/ }
> > 	auto foo2(T...)(T args) { /+ ... +/ }
> >
> > are very common.
> >
> >
> > Why not just supporting the syntax
> >
> > 	auto foo1(auto arg) { /+ ... +/ }
> > 	auto foo2(auto args...) { /+ ... +/ }
> >
> > to make things easier?
> >
> > People can still say typeof(arg), typeof(args[0]), etc., just
like
> > before, but it's a lot easier (and cooler!) to have a code with
all
> > inferred types, rather than explicitly typed templates.
> >
> > Any ideas?
> And what benefit would that really be? Using auto like that would
have to be
> converted to a template anyway. It's not like a function can
magically take
> any type for a parameter. The type must be known. Templates do
that by
> generating a new version of the function for every new set of
template
> parameters. auto couldn't do it without being turned into a
template. And then
> you're just covering up the template syntax with some potentially
confusing
> syntactic sugar. You wouldn't have any template constraints, which
would mean
> that the error messages would be horrible. You _can't_ explicitly
instantiate
> the template anymore if you need to, and it doesn't give you any
more type
> inference than you do with templates. It's not even any less
typing! In fact,
> it's exactly the same number of characters. All such a feature
would do would
> be to hide the fact that templates were being used, and since you
need to
> understand templates to use D properly - especially when dealing
with Phobos -
> that doesn't help at all.
> I see no advantages with this idea and quite a few disadvantages.
This
> proposal adds absolutely nothing.
> - Jonathan M Davis


o__o way to bash the proposal, it actually convinced me lol...

On 6/3/2011 11:47 AM, Mehrdad wrote:
> == Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article

>> understand templates to use D properly - especially when dealing
> with Phobos -
>> that doesn't help at all.
>> I see no advantages with this idea and quite a few disadvantages.
> This
>> proposal adds absolutely nothing.
>> - Jonathan M Davis
>
>
> o__o way to bash the proposal, it actually convinced me lol...


>> proposal adds absolutely nothing.
You will get this frequently. Especially if you identify with Java development.

Welcome to D forum, where new idea are squashed and maybe re-discussed later. Look up my name as Matthew Ong. Avoid asking the same questions.

http://www.digitalmars.com/d/
Notice: We *welcome feedback about the D compiler or language*,

Not so true. Or out right should warn people as:

Notice: Take it the way how we like it here, we are Not Burger K*ng.
Please see:
d.D.learn
AND MAKE sure you read this
d.D.NoSuchUselessSuggestion

What do you think D forum people, at least new people here are for warn.
Add a bit of humor into that.

I do see a pattern here. Just joined D forum less than 4 weeks ago.
Got a week off to clear my head. I think now I understand why D is still
such a small community in the forum.

-- 
Matthew Ong

On Fri, 03 Jun 2011 11:19:14 -0400, Matthew Ong <ongbp@yahoo.com> wrote:

> On 6/3/2011 11:47 AM, Mehrdad wrote:
>> == Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
>
>>> understand templates to use D properly - especially when dealing
>> with Phobos -
>>> that doesn't help at all.
>>> I see no advantages with this idea and quite a few disadvantages.
>> This
>>> proposal adds absolutely nothing.
>>> - Jonathan M Davis
>>
>>
>> o__o way to bash the proposal, it actually convinced me lol...
>
>
>  >> proposal adds absolutely nothing.
> You will get this frequently. Especially if you identify with Java development.

Please understand two important things:

1. We are open to proposals of new features, as long as you are open to having them rejected.  I have had several ideas that have been incorporated (array appending update, scoped const (inout) ) and have had 10x that amount rejected.
2. Do not take offense to being bashed -- there are literally 2 or 3 new proposals for the language a week.  These come in two forms.  The first are what I'd call "preferences" or "I wish D did things just like X" where X can be substituted for Java or Python or whatever your favorite bikeshed is called.  These kinds of proposals rarely go anywhere, because D usually already supports the requested functionality, just with a different style.  These are (understandably) met with statements like the above, especially if the community has already discussed such features ad-nauseum.

The second form are proposals that solve a problem that D has.  When these come about, usually there is a lively discussion which talks about the merits of such a proposal weighted against the drawbacks.  Look for the recent discussion about casting for an example.  Note that usually the people who maintain the language are going to be resistant to change -- a frequently changing language can lead to a completely unstable or unimplementable one.  You need to really convince everyone that your idea is worth changing the language (and potentially breaking existing code).  There are lots of subtle consequences to introducing changes.

Many times (and this was the case with your proposals), someone brings up an idea that has been discussed and rejected already.  It's sort of unfair to the person just joining the community to be rejected immediately -- they weren't a part of the original discussion.  But it's also tiresome to continually argue the same things over and over with new people.  I think this is just the way things are, and will always be.

> http://www.digitalmars.com/d/
> Notice: We *welcome feedback about the D compiler or language*,
>
> Not so true. Or out right should warn people as:
>
> Notice: Take it the way how we like it here, we are Not Burger K*ng.
> Please see:
> d.D.learn
> AND MAKE sure you read this
> d.D.NoSuchUselessSuggestion
>
> What do you think D forum people, at least new people here are for warn.
> Add a bit of humor into that.
>
> I do see a pattern here. Just joined D forum less than 4 weeks ago.
> Got a week off to clear my head. I think now I understand why D is still
> such a small community in the forum.

Go into any community which has a decade of discussion and structure under its belt and say "I'm new here, I think we should change everything to be the way I like it," and see how far you get.  This is not a property of D, it's a property of a stable development process.  We resist change, but we are open to *new* ideas and creative solutions.  For me, I'd rather be bluntly told "this is never going to be accepted, forget about it" than waste time arguing something that has no chance of success.

Yes, we welcome feedback about the D compiler or language, but you should also welcome feedback as to why your ideas might not work.  Just because you are not successful in your suggestions is not because of some deep-seated hatred for your original language.

-Steve

I don't see the problem, Jonathan explained it pretty well. If someone gets insulted because their feature request was objectively shot down then someone is taking themselves a little bit too seriously. :)

On 6/2/11 10:16 PM, Mehrdad wrote:
> I just thought of something:
>
> The patterns
>
> 	auto foo1(T)(T arg) { /+ ... +/ }
> 	auto foo2(T...)(T args) { /+ ... +/ }
>
> are very common.
>
>
> Why not just supporting the syntax
>
> 	auto foo1(auto arg) { /+ ... +/ }
> 	auto foo2(auto args...) { /+ ... +/ }
>
> to make things easier?
>
> People can still say typeof(arg), typeof(args[0]), etc., just like
> before, but it's a lot easier (and cooler!) to have a code with all
> inferred types, rather than explicitly typed templates.
>
> Any ideas?

Walter and I were looking very seriously at this around the beginning of 2008, with exactly the same syntax. At some point I recall we discussed a "static" version too.

That was just before we invented template constraints, and around the time when the discussion of C++ concepts were very intensively discussed. C++ concepts ended up not being adopted, but the discussions and past experience with C++ have revealed one important truth: you _almost never_ want a completely unconstrained template. Most any template (aside from the trivial identity function) wants to restrict the types it accepts. max() wants its parameters to be comparable. equal() wants its parameters to be iterable. map() wants its first argument to be a unary function that applies to the elements of the iterable second argument. And so on.

Even seemingly completely generic functions such as "to", which accepts most any type, are carefully specialized on type categories (classes, structs, enums, primitives, etc.) By the time all has been said and done, there are extremely few cases in which one ever wants to say "I'll take any argument here, and I don't care about its type". What we realized, therefore, was that such a feature would be usable very rarely, and furthermore it would simply encourage bad practice and sloppy programming (unrestricted templates are black holes that accept everything but then fail to compile with unintuitive error messages and loci).

(Cross one element off my wishlist: use "loci" at least once in 2011.)

Following the C++ concepts saga has helped us enormously. First, we realized that going that way would collapse D (as they nearly collapsed C++). Second, we figured we needed a simple, lightweight means to curb templates, and that's how restricted templates were born. It's one of our best ideas, and it has dramatically improved generic coding in D.


Thanks,

Andrei

On 6/3/11 10:19 AM, Matthew Ong wrote:
> On 6/3/2011 11:47 AM, Mehrdad wrote:
>> == Quote from Jonathan M Davis (jmdavisProg@gmx.com)'s article
>
>>> understand templates to use D properly - especially when dealing
>> with Phobos -
>>> that doesn't help at all.
>>> I see no advantages with this idea and quite a few disadvantages.
>> This
>>> proposal adds absolutely nothing.
>>> - Jonathan M Davis
>>
>>
>> o__o way to bash the proposal, it actually convinced me lol...
>
>
>  >> proposal adds absolutely nothing.
> You will get this frequently. Especially if you identify with Java
> development.
>
> Welcome to D forum, where new idea are squashed and maybe re-discussed
> later. Look up my name as Matthew Ong. Avoid asking the same questions.
>
> http://www.digitalmars.com/d/
> Notice: We *welcome feedback about the D compiler or language*,
>
> Not so true. Or out right should warn people as:
>
> Notice: Take it the way how we like it here, we are Not Burger K*ng.
> Please see:
> d.D.learn
> AND MAKE sure you read this
> d.D.NoSuchUselessSuggestion
>
> What do you think D forum people, at least new people here are for warn.
> Add a bit of humor into that.
>
> I do see a pattern here. Just joined D forum less than 4 weeks ago.
> Got a week off to clear my head. I think now I understand why D is still
> such a small community in the forum.

I understand how you find that an attractive conclusion to reach, but probably a more rational hypothesis is that some of your proposals have been of poor quality. That doesn't reflect poorly on your abilities, it just suggests that you have not yet accumulated sufficient expertise with D.

As an example, look at the activity of a current poster who proposed very strongly a change in a way the intervals are handled. It was arguably a very poor proposal for D, and people did their best to explain why. That poster was outwitted by competent people with clear and solid arguments. Yet that poster's way to solve that cognitive dissonance - the low road if you ask me - was to conclude that the value of his proposal is high in spite of all logic and reasoning, and that everyone else is wrong.

I suggest you don't fall for the same pattern, though clearly I understand how attractive it is. It slows down learning.


Andrei

On 6/3/2011 11:16 AM, Mehrdad wrote:

>But it's also tiresome to continually argue the same things over and >over with new people.  I think this is just the way things are, and >will always be.
Have you ever wonder why that pops up over and over again by your own
experience? Perhaps people knows that is the useful syntax? Nope,
the world changed in the last 3-4 years, and shocked a lot of people.

Past does not define the future. Just like C++ people mocked at Java 1.0
or Java mocked at C# does not mean those idea are alll bad?

The only constant in history is: Past does not define the future.

Walter and I were looking very seriously at this around the beginning of 2008, with exactly the same syntax. At some point I recall we discussed a "static" version too.

+

Many times (and this was the case with your proposals), someone brings up an idea that has been discussed and rejected already.

=
>AND MAKE sure you read this
>d.D.NoSuchUselessSuggestion

See, I do understand your frustration targeted at newbie with such
suggestion.

Personally I think Mehrdad did a good job in suggesting this new syntax.
He might have been exposed in other modern language like X?

Feel free to shoot this down like a bug also.

-- 
Matthew Ong
email: ongbp@yahoo.com

On 6/3/11, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> (unrestricted templates are black holes that accept
> everything but then fail to compile with unintuitive error messages and
> loci).

Agreed for that point, but as a templated function gets several
constraints it's impossible to figure out which constraint failed just
by looking at the error message. The only thing you ever get back is:
"<complex template declaration> does not match any function template
declaration"
"<complex template declaration> cannot deduce template function from
argument types <your arguments here>"

You get to see which arguments you've passed, but not which of the constraints failed. If you wrote the template it might be easy to figure out that you can't pass a certain type of argument, but if you didn't write it it's hard to figure out what went wrong.