Annotation of functions

[Adam D. Ruppe]

On Tuesday, 20 February 2018 at 12:15:57 UTC, psychoticRabbit 
wrote:
> I've noticed that Go and Rust annotate functions.
>
> func (in go)
> fn (in rust)
>
> I was kind of wondering why they made that choice, given 
> compilers in many languages do not.

A lot of dynamic languages do too

def foo(): # python
function foo() {} // javascript
etc.

I suspect a good chunk of it is just to make it look more 
familiar to them. It might also have been so they can hack up 
"goto definition" features in editors without a real parser...

> Everything else seems to have an annotation (e.g structs, 
> classes.) So why not functions?

The reason is just that we don't need it - the pattern of code 
makes it quite obvious to the compiler what is and isn't a 
function.


But like someone else said, we can already optionally tag stuff. 
Two ways:

enum Function;

@Function void foo()


or a simple comment:

/// function foo
void foo() {}



We also have various goto definition features from parsers. In 
fact, I added something for this to my editor just this last 
saturday.

It is a macro that runs "doc2 --locate-symbol=name.here -" and 
pipes the current source code to it, then goes to the line it 
returns.

There's also `dmd -X` and `dscanner` both of which can read a 
list of files you give it and find a definition. (mine is 
different in two ways: 1) it looks up in scope and can do 
fully-qualified names and 2) it works with pipes instead of 
written files, so it can parse on demand)

$ cat simpledisplay.d | ~/program/d-diff/doc2 --locate-symbol 
SimpleWindow.impl -
2018


and, of course, 2018 is the line where impl is introduced. impl 
is a mixin template btw - so the parser approach works on more 
than just functions!