Proposal: Function declaration with keyword

[Jason House]

Hans W. Uhlig wrote:

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

How do out parameters get handled when handling multiple return types?  Is
there a way to mix a=b() syntax with b(a)?