| |
 | Posted by Pallavering |  Permalink Reply |
|
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.
|
