View mode: basic / threaded / horizontal-split · Log in · Help
June 03, 2011
How about "auto" parameters?
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?
June 03, 2011
Re: How about "auto" parameters?
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
June 03, 2011
Re: How about "auto" parameters?
== 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...
June 03, 2011
Re: How about "auto" parameters?
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
June 03, 2011
Re: How about "auto" parameters?
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
June 03, 2011
Re: How about "auto" parameters?
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. :)
June 03, 2011
Re: How about "auto" parameters?
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
June 03, 2011
Re: How about "auto" parameters?
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
June 03, 2011
Re: How about "auto" parameters?
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
June 03, 2011
Re: How about "auto" parameters?
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home