Proposal: Function declaration with keyword

[Hans W. Uhlig]

Bill Baxter wrote:
> boyd wrote:
>> Okay, so I've been working with D for a while now. I stumbled upon it 
>> when I was searching for a better language for me to use.
>  >
>> Other languages always seemed to lack some crucial feature. D is 
>> generally easy to use, easy to read and has all the options I wanted. 
>> I also love the attention it has given to little details that just 
>> make things so much easier.
>>
>> It's not perfect by any means, but overal it's better than anything. I 
>> currently have gripes with mixins, which are a pain to use. From what 
>> I hear Macros are gong to replace them, so for now I'll avoid that 
>> subject.
> 
> Heartily agree with you there.  For all the complaining I do here, I 
> still keep using D, because I really haven't found anything better.
> 
>>
>>
>> Instead I've been wondering about a problem that, to my knowledge, 
>> hasn't gotten any attention yet: function declaration keyword.
>>
>> One thing I never really liked about C++ is the way function 
>> declarations look. You can't easily differentiate them from variable 
>> declarations. Maybe it's partly because I started with Object Pascal 
>> rather than C++, but I never got used to it.
>>
>> Anyway, why not use a keyword for function declarations?
>>
>>   function void DoSomething(int someParam);
> 
> I just hope I don't ever have to type this in D:
> 
>   protected override invariant pure function invariant(double)[] 
> func(invariant (double)[]) {...}
> 
> Scarily, it's looking like that's probably going to be quite a 
> reasonable signature for a D2 pure method to have.  (Except for the 
> 'function' part from your suggestion).
> 
> For whatever else, K&R knew the value of keeping common keywords short, 
> even if it meant using abbreviations.  That's why we have
> - int not integer
> - char not character
> - const not constant
> - enum not enumeration
> - float not floating_point
> and later, thanks to Stroustrup, I guess:
> - bool not boolean
> 
> 
> So anyway, if it is going to become required on every function, let's at 
> least make it something shorter than 'function'.
> 
> I think the chances of it happening are slim and none, though.  Unless 
> you can come up with some more compelling reasons for it.  Heck we can't 
> even get Walter to remove 'printf' from Object.d.
> 
> --bb
I would think this was more the case as you had significant resource 
limitations that you had to begin with. I think a lot of older school 
programmers would like to see would be nice tight code output, a little 
verbosity in the language isn't bad, it makes it readable and more 
expressive. We have Terrabyte hard drives and gigs of working memory on 
programming stations so a large text files are not a problem(and yes I 
know some of you work on 4MB 286s running a self rolled linux and vi, a 
50k sourcefile still wont kill you)  as long as what it puts out on 
compiling is small and tight, a couple extra kilobytes in source wont 
hurt us. The binary should be tight, not the source code.  The whole who 
needs more then 640k idea is outdated. Java has some right ideas that 
methods, keywords and attributes being descriptive(and no I don't 
support 
thisMethodTakesTwoValuesAndMultiplysThemOutAfterAskingTheUserMethod(int, 
int) {} that is just plain overkill.)