Proposal: Function declaration with keyword

[Hans W. Uhlig]

boyd wrote:
>> So anyway, if it is going to become required on every function, let's 
>> at least make it something shorter than 'function'.
> 
> I personally prefer the keyword 'function', it's not that long and it's 
> clear. Shorter is okay as long as it doesn't decrease readability. I'm 
> wary of using 'func', as it could also indicate functor. I have no Idea 
> what a functor is but i've seen it used around here several times. 
> Anyway, are those 8 characters really such a pain to write?
> 
> Regardless of what keyword will be used, the main reason for using a 
> keyword in the first place is readability. Not just for the user, but 
> also for the parser. I'm not an expert on parsing, but I'm pretty sure 
> this keyword could help identifying functions more easily.
> 
> Plus there won't be any need for those special case storage classes like 
> 'pure' and 'const' to be written at the end of the function, decreasing 
> the overal complexity of the D Language. Decreasing complexity of the 
> basic features becomes more and more important when more features are 
> added to D.
> 
>> 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.
> 
> Having a keyword for function declarations is a completely different 
> matter from removing one lousy function in the standard library.
> 
> The chances of this feature from happening depends on whether this 
> proposal appeals to the ideas of the designers of D, and partly on what 
> the D community thinks of it. So, there's really no telling what kinds 
> of odds we're dealing with here.
> 
>> I just hope I don't ever have to type this in D:
>>
>>    protected override invariant pure function invariant(double)[] 
>> func(invariant (double)[]) {...}
> 
> This function would be even better if the implementation was: { return 
> _myArray; } :P
> Seriously, I don't think the function declaration keyword really affects 
> this problem.
> 
> Anyway, thanks for the feedback.
> 
> Cheers,
> Boyd
> 
> 
> 
> --------
> On Sat, 12 Apr 2008 14:16:29 +0200, Bill Baxter 
> <dnewsgroup at billbaxter.com> 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
Update to my prior notes:

<modifier ...> <type> <identifier><(parameter, ...)> <property ...> 
<{block}>

where modifier is:
  const, static, pure, invariant(can a function or class be invariant?), 
etc...
where type is:
	class, function, etc...
where identifier is:
	the human identifier of the declaration
where parameter defined as:
	<modifier ...> <type> <identifier>
	where modifier is:
		const, static, final, invariant, volitile(cpu optimization for 
loops?), etc.
	where type is:
		int, double, float, void, etc.
	where identifier is:
		the human identifier of the declaration
where property is:
	<property <entry, ...>>	
	returns <parameter, ...>, throws?, (more later?)
where block is:
	code!

curious, someone mentioned before using in, out and ref... These are 
unknown to me, could someone give me a quick gist or point me to a page, 
  if so I will update this.