Proposal: Function declaration with keyword

boyd gaboonviper at gmx.net
Sat Apr 12 06:17:47 PDT 2008


> 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



More information about the Digitalmars-d mailing list