Proposal: Function declaration with keyword

[Georg Wrede]

Hans W. Uhlig wrote:
> 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.
> 
> 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, 

Yes.

> a little verbosity in the language isn't bad, it makes it readable
> and more expressive.

It's called redundancy. So, if a keyword is 12 characters long, it 
pisses off everybody. But, if there's some subtle redundancy in the 
syntax (as opposed to C(++), where there's almost none, which results in 
you being able to write just anything and it's acceptable code -- in 
other words, it may not be syntactically wrong, it simply does something 
else than you possibly could have imagined), the code and the error 
messages the compiler can give you become vastly more helpful /towards/ 
effort per hour productivity.

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

Stab ignored. :-)  (Not to mention, I can actually show you a machine 
that corresponds to your specs..., except that the 286s rarely had 4MB 
of RAM. The issues with 286 were more like whether you had 0.6MB or 
1.0MB, and if so, what had the tweaks and kludges been to actually claim 
the usability of the 1MB. Look up on Google, issues like XMS and EMS.)

A programming language ought to work as well, whether you have "a 
default *386*" or "the coolest 16-CPU 16GB, 4MHz, 16TB HD" machine.

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

An eighth of the 640K with D goes to the standard library. That means, 
that there's no way of running like 7 TSRs written in D, and then have 
enough RAM to use for your regular program.

This wouldn't bug me, if it weren't that my definition of a Systems 
Programming Language implies usability with arbitrary processors. As it 
stands now, D with PIC -- just forget it. D with

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