Proposal: Function declaration with keyword

[Hans W. Uhlig]

Jason House wrote:
> 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
Thank you, However after reading that, in, out, ref and lazy seem to be 
simply modifiers to parameters for the scope of the function definition, 
I am unsure as to how that would change this definition.