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.

Would this be a useful feature in D?

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

What are people's thoughts about it?

My first thought is to make it an optional annotation, for the benefit of developing source code analysis tools that can 'more easily' find functions in source code (i.e. The D compiler can just strip it off and do nothing with it.).  That way programmers that see no benefit in it, don't have to deal with it.

On 20/02/2018 12:15 PM, 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.
> 
> Would this be a useful feature in D?
> 
> Everything else seems to have an annotation (e.g structs, classes.) So why not functions?
> 
> What are people's thoughts about it?
> 
> My first thought is to make it an optional annotation, for the benefit of developing source code analysis tools that can 'more easily' find functions in source code (i.e. The D compiler can just strip it off and do nothing with it.).  That way programmers that see no benefit in it, don't have to deal with it.

You need a fully implemented frontend to get anything proper in terms of parsing for D.
We're not talking about syntax highlighting here.

So the point is moot.

On Tuesday, 20 February 2018 at 12:18:47 UTC, rikki cattermole wrote:
> You need a fully implemented frontend to get anything proper in terms of parsing for D.
> We're not talking about syntax highlighting here.
>
> So the point is moot.

Why is the point (about being able to more easily find functions) moot?

At the moment, i can't even grep source code for functions.

i can for structs. i can for classes. but I can't for functions.

if function were annotated, I could grep for that annotation.

That's really the only benefit I see in it.

On 20/02/2018 12:35 PM, psychoRabbit wrote:
> On Tuesday, 20 February 2018 at 12:18:47 UTC, rikki cattermole wrote:
>> You need a fully implemented frontend to get anything proper in terms of parsing for D.
>> We're not talking about syntax highlighting here.
>>
>> So the point is moot.
> 
> Why is the point (about being able to more easily find functions) moot?

string creater() pure {
	return "void func() {}";
}

mixin(creator());

That is why. There are plenty of functions, classes and structs that simply won't exist in the form of syntax until you execute CTFE.

On Tuesday, 20 February 2018 at 12:45:25 UTC, rikki cattermole wrote:
>
> string creater() pure {
> 	return "void func() {}";
> }
>
> mixin(creator());
>
> That is why. There are plenty of functions, classes and structs that simply won't exist in the form of syntax until you execute CTFE.

I think I'd fire anyone that wrote functions in that way ;-)

perhaps what I had in mind was a lot simpler.

fn string creater() pure {
 	return "void func() {}";
}

so now I'm just looking for lines that begin with fn. the mixin doesn't matter.

the only reason I thought of this annotation thing, was so I could grep a source code file and count how many functions it had in it. this seemed the easiest way ;-)

at the moment, that's just not possible - as you mentioned, you need a front end to process that kind of information (unless you have an annotation).

On Tuesday, 20 February 2018 at 12:55:31 UTC, psychoticRabbit wrote:
> fn string creater() pure {
>  	return "void func() {}";
> }
>
> so now I'm just looking for lines that begin with fn. the mixin doesn't matter.

oh... I think I might have misunderstood your point ... due to not understanding CTFE. Never used it before - 25+ years programming ;-)

what does this code even do? i don't understand it. why does it even compile?


string creator() pure {
	return "void func() {}";
}

mixin(creator());

On Tuesday, 20 February 2018 at 12:18:47 UTC, rikki cattermole wrote:
>
> So the point is moot.

ok. I've come around... and the point reall is moot.

so.. in that case..another idea...how about a compiler option to output a list of functions. (I don't really expect many will warm to that idea.)

Does anyone know of any tool that could do such a thing?

I just want of a list of functions from a source code file.

Who would have thought it would be that hard ;-)

psychoticRabbit wrote:

> On Tuesday, 20 February 2018 at 12:18:47 UTC, rikki cattermole wrote:
>>
>> So the point is moot.
>
> ok. I've come around... and the point reall is moot.
>
> so.. in that case..another idea...how about a compiler option to output a list of functions. (I don't really expect many will warm to that idea.)
>
> Does anyone know of any tool that could do such a thing?

dmd.

dmd -X will output alot of interesting info.

On Tuesday, 20 February 2018 at 12:55:31 UTC, psychoticRabbit wrote:
> On Tuesday, 20 February 2018 at 12:45:25 UTC, rikki cattermole wrote:
>>
>> string creater() pure {
>> 	return "void func() {}";
>> }
>>
>> mixin(creator());
>>
>> That is why. There are plenty of functions, classes and structs that simply won't exist in the form of syntax until you execute CTFE.
>
> I think I'd fire anyone that wrote functions in that way ;-)
>

Why would you fire someone for writing idiomatic D?

It was kind of a bad example given, but there are legitimate reasons to generate functions like that.

Ex.

mixin template Property(T, string name)
{
    mixin("private T _" ~ name ~ ";");

    @property
    {
        mixin("T " ~ name ~ "() { return _" ~ name ~ "; }");

        mixin("void " ~ name ~ "(T newValue) { _" ~ name ~ " = newValue; }");
    }
}

mixin template ReadProperty(T, string name)
{
    mixin("private T _" ~ name ~ ";");

    @property
    {
        mixin("T " ~ name ~ "() { return _" ~ name ~ "; }");
    }
}

mixin template WriteProperty(T, string name)
{
    mixin("private T _" ~ name ~ ";");

    @property
    {
        mixin("void " ~ name ~ "(T newValue) { _" ~ name ~ " = newValue; }");
    }
}

On Tuesday, 20 February 2018 at 13:39:17 UTC, bauss wrote:
> On Tuesday, 20 February 2018 at 12:55:31 UTC, psychoticRabbit wrote:
>> On Tuesday, 20 February 2018 at 12:45:25 UTC, rikki cattermole wrote:
>>>
>>> string creater() pure {
>>> 	return "void func() {}";
>>> }
>>>
>>> mixin(creator());
>>>
>>> That is why. There are plenty of functions, classes and structs that simply won't exist in the form of syntax until you execute CTFE.
>>
>> I think I'd fire anyone that wrote functions in that way ;-)
>>
>
> Why would you fire someone for writing idiomatic D?
>
> It was kind of a bad example given, but there are legitimate reasons to generate functions like that.
>
> Ex.
>
> mixin template Property(T, string name)
> {
>     mixin("private T _" ~ name ~ ";");
>
>     @property
>     {
>         mixin("T " ~ name ~ "() { return _" ~ name ~ "; }");
>
>         mixin("void " ~ name ~ "(T newValue) { _" ~ name ~ " = newValue; }");
>     }
> }
>
> mixin template ReadProperty(T, string name)
> {
>     mixin("private T _" ~ name ~ ";");
>
>     @property
>     {
>         mixin("T " ~ name ~ "() { return _" ~ name ~ "; }");
>     }
> }
>
> mixin template WriteProperty(T, string name)
> {
>     mixin("private T _" ~ name ~ ";");
>
>     @property
>     {
>         mixin("void " ~ name ~ "(T newValue) { _" ~ name ~ " = newValue; }");
>     }
> }

I should probably have put an example usage to show how it's used:

class Foo
{
    mixin Property!(int, "bar");

    mixin Property!(string, "baz");
}

void main()
{
    auto foo = new Foo;
    foo.bar = 100;
    foo.baz = "Hello";

    import std.stdio;

    writeln(foo.bar);
    writeln(foo.baz);
}