Interested in contributing to D!

[Pallavering]

Hello!

I have been on and off the programming scene in private and would
like to contribute to the Open Source community. I chose D because
I see that it has some potential, yet it hasn't exactly left the
ground and took off to the skies, as some initially hoped some
years ago. There are a couple of things that are holding D back,
and I would like to contribute to fixing this issue.
I know that I won't be the first to start with some ambition here,
and I haven't seen a lot of people taking care of our sweet D 
baby.
It should be imperative for any language that wants to be seen as
usable and programmer-friendly to not just have an excellent 
compiler
capable of enforcing its own rules, but also to meticulously,
methodically and rigorously (like true mathematicians!) document 
and present
these rules to prospective developers as well as to have tools 
that analyze code
correctly according to these rules and assist the programmer
in doing his job.
With some D declaration generators that pull their declarations
from C/C++ headers or from ObjC code files (which by all means do
not have to be implemented in the D compiler itself!), the chronic
lack of industry-proven libraries for D and the lackluster porting
efforts to D could be a thing of the past. (I am writing this
because I have absolutely no idea which direction the D community
and the D language are going right now :D)

To start right off, I have a question which might illustrate what
I mean when I say that it has potential but keeps people back.

Recently, I came across the 
[libdparse](https://github.com/dlang-community/libdparse) library 
and (through a couple clicks) stumbled upon 
[this](https://github.com/dlang-community/libdparse/issues/370#issuecomment-531049896).
Specifically, this snippet:

     public @safe @wow pure void prefixAttrs(int x) {}
     public void suffixAttrs(int x) @safe @wow pure {}

The comment goes on to say that, depending on whether the 
attributes
are written before or after the function declarator, the 
attributes
end up parsed and stored in completely different arrays, adding
that

> `libdparse` is just weird here.

I was intrigued by what the D language reference had to say about 
this,
since I thought that libdparse would be following the rules as 
close as
possible, and found the reference silent on this issue, which 
gives
`libdparse` and the compiler a blank cheque on how to interpret 
this.
Given that there is nothing said about this in the language 
grammar,
are there any subtle differences between the two functions
that I need to know about? And how does the D community feel about
the language and its quirks, does it need more streamlining or 
should
the language branch out to cover more cases?

This is specifically something that should not happen in a 
language
that has matured so much, yet retains these kinds of rather 
obvious
loopholes, making developers of toolchains for D wary about them 
and
ultimately attracting them to other languages, where D would 
certainly
have had a chance.

Now, given that this is a very isolated incident with 
insignificant
reach (who the hell cares if I write it before or after the 
function
name? - I certainly do!), I can understand that the D community 
is not particularly
poised to fix these little loopholes and the according 
documentation;
after all, it is a lot of work, and a very unthankful job. I 
believe
though that - by making the bottom-line of this language 
beautiful and
supple and sharpening the D language tools (and maybe with a hard
transition to D3 to get rid of some old baggage) - we can make
our job much easier in the long run.

It took me a lot of words to say: you've probably got yourselves
another D community member. Albeit a very critical one.