1. The filename characters have to be valid D identifier characters. This annoys some people.

2. Because Windows has case-insensitive filenames, and Linux, etc., have case sensitive filenames, we recommend that path/filenames be in lower case for portability. This annoys some people.

3. There are command line switches to map from module names to filenames for special purposes. They're very rarely needed, but invaluable when they are.

Overall, it's been very successful.

> 2. Because Windows has case-insensitive filenames, and Linux, etc., have case sensitive filenames, we recommend that path/filenames be in lower case for portability. This annoys some people.

That's also a problem in most other languages; just a couple of days ago, someone else's C++ code didn't compile on my machine because they had accidentally included <something/whatever.h> when the file was actually named <something/Whatever.h>, because macOS is case insensitive. I had the same experience with JavaScript some months ago, that time because they were running Windows.

On the "filenames must be valid identifiers" thing; I really wish more languages would start allowing kebab-case in identifiers. That's also absolutely not a D thing, more of a common complaint about most languages.

Kebab-case is, in my opinion, the most beautiful of identifier cases, but how would you get around the ambiguity with subtraction, short of going full Lisp or adding whitespace sensitivity?

I don't think requiring whitespace around operators is such a bad thing. My personal coding style generally looks like `int foo = 10 + (something - 20);` anyways, and I think that style is a lot more readable than `int foo=10+(something-20);`. If you require whitespace around almost all operators, you open up the possibility of naming identifiers basically anything, which lets you have conventions like naming predicates or boolean members with a question mark at the end. In my opinion, `myObject.whatever?` looks a lot better than `myObject.isWhatever`.

Exactly which operators should require whitespace and which don't is up for debate, but in my personal opinion, requiring space around infix operators and letting prefix/postfix operators not require a space would be appropriate. Nobody wants to have to write `myArray [i]`, but I think most people would be willing to give up `i-1` and instead write `i - 1`.

I like to be able to remove spaces in complex expressions, for readability issues. For instance, this :

    t[x] = t[x-1] + t[x-2]

looks more readable to me than this :

    t[x] = t[x - 1] + t[x - 2]

Another example :

    y = a*x1 + b*x2 + c

> adding whitespace sensitivity?

Would adding whitespace sensitivity really be a problem? You already need whitespace to separate identifiers, so it's not a totally foreign concept in mainstream languages.

It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands.

>> It seems like we've been making a weird trdeoff, by disallowing kebab-case just so we can smash our operators together with our operands.

Some people don't want to bother putting a space between operators and operands, and proponents of kebab-case just don't want to push the shift key to get an underscore.

To get kebab-case, the restriction that identifiers cannot start or end with '-' gets you pretty far. The only whitespace change is that you sometimes need whitespace around an infix '-'. Other operators are still fine, and it still works fine for prefix and postfix operators.

Also, the reason to prefer kabab-case for me has nothing to do with avoiding a keypress. It's that I find kebab-case easier to read.

As the other poster mentioned, you gain more than just the dash when forcing white space; you get forced readability and characters like / ? and ^ in identifiers. Then you can name things like foo/bar or e^x

I suppose I could get used to that, but it sounds like a nightmare at first blush.

I don't think I could handle i ++ instead of i++

You wouldn't have to require whitespace around all operators; you could, for example, decide that infix math/bitwise/logic operators must have a space around them, while other operators (like the infix operators `.` and `->`, and the prefix/suffix `++`, `--`, `[...]`, and `!`) wouldn't require whitespace.

I agree that nobody would want to write `i ++` or `foo [10]` or `myvar . mymember`, but I think a lot of people could get behind `10 - 20` and `foo && bar` instead of `10-20` and `foo&&bar`.

Does one actually need whitespace to separate identifiers? This is something that's always bugged me a bit.

Aside from C-style type declarations ("unsigned int x;"), C-style syntaxes seem to always have ways other than whitespace to separate identifiers.

Like (using some JavaScript in a hypothetical example) I can't think of many concrete reasons why this is easier to parse:

  let first_number=2, second_number=2, answer=first_number-second_number;

...than this:

  let first number=2, second number=2, answer=first number-second number;

Although, of course, some languages—most Lisps, Tcl, and Red/REBOL come to mind—actually do rely on whitespace and whitespace alone to separate identifiers in many situations, and something like this would likely be unworkable there.

Though one can use whitespace in Common Lisp identifiers, by quoting symbols:

  CL-USER 115 > (let ((first| |number 10)
                      (second\ number 20))
                  (+ first\ number |SECOND NUMBER|))
  30

Oh, I never noticed that. That's pretty interesting—although unfortunately, that syntax does not look terribly convenient to write, which is the main thing I'm after here.

I think the best way to get identifiers with whitespace to work in a Lisp would be contrive a syntax for S-expressions that uses something other than whitespace to separate things. Perhaps letting (first rest-1 rest-2 ...) be written as as (first: rest 1, rest 2, ...) or (first, rest 1, rest 2, ...), so that example could be written as:

  (let: ((first number: 10), 
         (second number: 20)), 
        (+: first number, second number))

I imagine it would be possible to write a macro in Common Lisp to transform this into runnable code, or a language in Racket to do so—although, I'm not sure how many people would actually want to make or use something like this.

Not all whitespace you see in Lisp code is strictly necessary:

TXR Lisp:

  1> (list 1"a"'(b(c)d(e)))
  (1 "a" (b (c) d (e)))

Here we just have one space that prevents list 1 from being list1.

TikZ allows whitespace in identifiers. At first it was pretty strange, but I actually really like it now. I don't think parsing it is much of a problem, and I would quite like to be able to use it in other languages.

Well, thinking about it more, I did realize there's a pretty nasty edge case with my hypothetical JavaScript syntax:

  let let x = 5;
  let x = 6; 
  // should this set the variable "let x"?
  // or define a variable named "x"?

One could potentially design around situations like this, but allowing whitespace in identifiers likely does require being much more meticulous about treatment of reserved words, identifiers, and whitespace than more traditional syntaxes, and this is likely why not many people attempt this.

I think the idea is worth experimenting with, though, and that a good implementation of it could be convenient enough for end-users to outweigh the implementation inconvenience.

I generally separate operands, but in dense math expressions it's not always the best for readability.

   x = (-b + sqrt(b**2 + 4*a*c) / (2*a)
   
   x = (- b + sqrt(b ** 2 + 4 * a * c) / (2 * a)

... Although, one could argue that allowing tightened multiplication and division are enough.

Not to be that guy, but...

  x = (-b + sqrt(b**2 - 4*a*c) / (2*a)

lol, thank you.

Use +- for subtraction, where + is binary plus and - is unary minus.

Not sure if it's a good idea, but maybe try:

  foo-bar # kebab-case
  foo−bar # subtraction
  foo minus bar # subtraction? (infix identifier "minus")
  foo - bar # subtraction (infix identifier "-")
  foo − bar # subtraction (operator symbol)

using \u2212 as a explicit subtraction operator for people who really can't stand having 'extra' whitespace?

Perl6 allows it, and it's the preferred convention to boot.

Small Intro: https://perl6advent.wordpress.com/2015/12/05/day-5-identifie...

Use ‘−’ for subtraction, allow ‘–’ and ‘‐’ in identifiers, and report an error for ‘-’.

Sure, just make everyone replace their keyboard with one which has two `-` buttons and make everyone understand why they need two buttons for something which looks like the same letter and you can safely use – for one thing and — for the other.

Those people are easily annoyed.

> 1. The filename characters have to be valid D identifier characters. This annoys some people.

this could be solved by allowing strings in qualified imports

  import "illegal identifier"."some more weird unicode" as someLib;

Which, incidentally, is how Zig does it:

  const thing = @import("relative/path/to/thing.zig");
  const package = @import("packagename");

And rust

`extern crate foo`

`extern crate "foo-bar" as foo_bar`

This is all legal identifiers but

`use std::path::Path;`

`use std::path::Path as int; // For maximum confusion`

And not that anyone uses this part but:

`mod bazz;`

`#[path = "bazz-bar.rs"] mod bazz_bar;`

I haven't used D, but in Haskell we have the same module name == file name thing. The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory:

    import A      -- compiler reads A.hs
    import A.B    -- compiler reads A/B.hs

Thus, two semantically related modules are now in different directories.

Python, IMO, handles this correctly by having __init__.py support inside directories. It's theoretically less elegant because of the special name, but in practice leads to better file organization.

Same for Rust, but even better, because one can define nested modules in the same file. So you can either define a new module in the same file, put it in a different file named by the module, or put it in the file `mod.rs` inside the directory named by the module.

D also has package.d for the same effect as python. It works quite well as package is a keyword and thus can't be used as a regular module anyway.

But package.d could lead you to overdepend on too many modules too :) it's mostly great for end applications rather than internal to libraries.

Sure, but that's not specific to package.d. See the earlier convention of all.d or d.d. That's the trade-off with having public imports. I don't see how this is related to my comment though?

> The only time I don't like it is when we have nested modules, the parent and children modules are not in the same directory:

> import A -- compiler reads A.hs

> import A.B -- compiler reads A/B.hs

That has to happen at some level, assuming subdirectories; otherwise, what would "import A.B.C" refer to?