Proposal: Function declaration with keyword

[Jason House]

Hans W. Uhlig wrote:

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

See "function parameters" section at
http://www.digitalmars.com/d/1.0/function.html