We all know how nice well-written idiomatic D code looks, but I think it's time that we try to really explore the full power of the language.

To further this goal, I've started the Idiotmatic D repository on Github. It is a place where we do not just ask, "What should we do?, but also ask, "What CAN we do?". I aim to create examples of clean-ish idiotmatic code for those new to D to follow (at their own peril).

The rules are simple: The code does not have to run, but it does have to compile.

Contributors are encouraged to do things like look at the Declarations page of the language reference and ask themselves "Does this mean that I'm allowed to _____?" where the blank is filled in with a really bad idea.

For instance the code:

alias double ["a" .. "whatever"] ( * foo []) [123.45f];

is both syntactically valid and banned by international war crimes treaties.

Does the spec let you do it but the compiler stops you? Leave it in, but commented out.
Does the spec let you do it and the compiler agrees? Good.
Does the spec disallow it but the compiler doesn't even issue a warning? Excellent.

https://github.com/Hackerpilot/Idiotmatic-D

On Sunday, 2 February 2014 at 01:50:50 UTC, Brian Schott wrote:
> To further this goal, I've started the Idiotmatic D repository on Github. It is a place where we do not just ask, "What should we do?, but also ask, "What CAN we do?". I aim to create examples of clean-ish idiotmatic code for those new to D to follow (at their own peril).

I think it was John Carmack who said, "whatever is syntactically valid will some day be in your codebase."

On Monday, 3 February 2014 at 07:18:39 UTC, qznc wrote:
> I think it was John Carmack who said, "whatever is syntactically valid will some day be in your codebase."

One of the reasons that I want to push for decreasing the number of thing that are syntactically valid.

Right now we have a mess of inaccurate specs, a compiler front end that accepts whatever the heck it feels like, and a culture of rumors and legends surrounding what's (going to be) deprecated and what isn't.

On 2/2/14, 11:30 PM, Brian Schott wrote:
> On Monday, 3 February 2014 at 07:18:39 UTC, qznc wrote:
>> I think it was John Carmack who said, "whatever is syntactically valid
>> will some day be in your codebase."
>
> One of the reasons that I want to push for decreasing the number of
> thing that are syntactically valid.
>
> Right now we have a mess of inaccurate specs, a compiler front end that
> accepts whatever the heck it feels like, and a culture of rumors and
> legends surrounding what's (going to be) deprecated and what isn't.

Hyperbole much?

On Monday, 3 February 2014 at 07:51:39 UTC, Brad Roberts wrote:
> Hyperbole much?

It is clear which features are going to be deprecated, and we know when and why.
The parser complies with the grammar specification.

Are these statements true?

On Monday, 3 February 2014 at 08:02:45 UTC, Brian Schott wrote:
> On Monday, 3 February 2014 at 07:51:39 UTC, Brad Roberts wrote:
>> Hyperbole much?
>
> It is clear which features are going to be deprecated, and we know when and why.
> The parser complies with the grammar specification.
>
> Are these statements true?

No, but them being false does not make your previous ones true either.
Anyway, I ike the idea behind yor repo. If I happen to find anything interesting, I will contribute for sure!

On 2/3/14, 12:02 AM, Brian Schott wrote:
> On Monday, 3 February 2014 at 07:51:39 UTC, Brad Roberts wrote:
>> Hyperbole much?
>
> It is clear which features are going to be deprecated, and we know when
> and why.
> The parser complies with the grammar specification.
>
> Are these statements true?

Nope.  But neither was your previous one.  Which of the two is closer to true?  This set, by a large margin.

Exaggeration and vague statements of problems does nothing other than inflame and spread FUD.

On Monday, 3 February 2014 at 08:38:16 UTC, Brad Roberts wrote:
> Nope.  But neither was your previous one.  Which of the two is closer to true?  This set, by a large margin.
>
> Exaggeration and vague statements of problems does nothing other than inflame and spread FUD.

I've listed many specifics before, but you'll have to hunt the newsgroup to find them. I'm sure they're right next to the official plan for the "delete" keyword, the "!<>" operator, and imaginary number literals.

How about the "D Logo and Slogan" thread? There's still confusion about which of the two equivalent alias syntaxes is more correct. I apparently made a static analysis rule that asks users to use the wrong one.

The "Which tools do you miss in D?" thread: A lot of these tools don't exist because the process of developing D tooling is an incredibly painful process of looking at the spec, Phobos, DMD's source code, and experimentation to figure out what D is, and even after having done all that I'm still not sure.

The real problem is that I don't think we care. Several people spoke about this at DConf last year and the only thing that's happened since then is that I've made people annoyed.

On Monday, 3 February 2014 at 09:43:42 UTC, Brian Schott wrote:
> I've listed many specifics before, but you'll have to hunt the newsgroup to find them. I'm sure they're right next to the official plan for the "delete" keyword, the "!<>" operator, and imaginary number literals.

So, here? http://dlang.org/deprecate.html

> The real problem is that I don't think we care. Several people spoke about this at DConf last year and the only thing that's happened since then is that I've made people annoyed.

Considering that fixing these problems are tedious and
unrewarding tasks, it's not surprising that so few people step up
to do it. Considering that this task does not require as much
knowledge/experience as, e.g., hacking the compiler, IMHO the
best people to get it done is those who actually need them done.

On 02/03/2014 10:43 AM, Brian Schott wrote:
> The real problem is that I don't think we care.
>

I care, but I don't believe in the official D grammar and would rather approach this problem by rewriting both grammar and parser completely in such a way that the grammar becomes legible and code that _looks_ legal becomes legal and code that _looks_ illegal becomes illegal.