Does D have too many features?

H. S. Teoh hsteoh at quickfur.ath.cx
Sat Apr 28 18:24:20 PDT 2012


On Sat, Apr 28, 2012 at 04:56:52PM -0700, Jonathan M Davis wrote:
[...]
> One _big_ difference between D and C++ as far as complexity goes is
> that in C++, a _lot_ of the complexity comes from weird things in the
> language and knowing about how certain things can go horribly wrong
> (e.g. I can never remember all of the details on how horribly broken
> multiple inheritence is). 

Ugh. C++ multiple inheritance is a labyrinth, nay, a veritable minefield
of subtle tripwires, inconvenient limitations, and a source of
hair-tearing headaches. It's one of the bigger problems with C++'s OO
implementation. Java's idea of single inheritance, multiple interfaces
is a much better concept.


> It's frequently not an issue of knowing how to do things in the
> language but rather an issue of knowing what weird side effects an
> problems happen with certain stuff. With D, on the other hand, the
> complexity tends to be in just knowing what all of the features are
> and what they can do.

Except is() expressions, which appear to be totally arbitrary to me. As
far as I'm concerned, it's just "memorize these bunch of arbitrary
special rules".


> The only feature that comes to mind as probably being overly complex
> is is expressions, but that complexity can really come in handy
> sometimes.  std.traits should probably do more to alleviate the need
> for is expressions though so that odds of needing some of the more
> complicated stuff are lessened.

Needing to rely on std.traits is backwards, IMO. It's the compiler that
knows all this stuff about types, why should we need to consult a
library to get at the information? But anyway, the *functionality* of
is-expressions are very useful, and, I'd argue, necessary. It's just
that the syntax is atrocious and needs fixing.


> * As for redundant features, the first one that really comes to mind
> is WYSIWYG string literals. There are what, 4 different types of
> delimiters for string literals?

Only 4? I thought there were more. Last I looked, there were like 6
separate cases.


> I don't even remember all of the options. I just always use ` if I
> don't want any escaping in string literal and " if I do. The others
> may be valuable enough to have in some contexts, but I _never_ use
> them.

Yeah, I agree we should merge some of the string literal syntaxes. Some
of them are useful (I'm a sucker for heredoc syntax) but currently it
seems like just way too many options for something that should be really
straightforward.


[...]
> * I hate C style struct initializers and would really like to see them
> go, but for reasons that I don't understand, people actually use them
> rather than using a proper constructor call, so I doubt that we could
> get rid of them without a fair bit of complaining. I think that
> they're completely redundant and very _un_D.

It's annoying to have to write a constructor whose only purpose is to
copy arguments into field members. Many uses of structs don't need the
encapsulation that ctors were intended for.


> * There seem to be too many ways to do variadic functions. We have to
> allow C style variadics for extern(C), but having 3 of our own seems
> like a bit much.  Variadic templates are generally all that we need.
> The others don't seem necessary for the most part. But unfortunately,
> they should probably be left in so that classes can use them with
> virtual functions, since they can't use templates.

IMO we should unify variadic syntax into one (or perhaps leave the C
variadics separate, since they're just for compatibility with C), and
let the compiler implement each appropriately for the given context.


[...]
> * Increasingly, I don't like UFCS. I think that in most cases, it
> complicates code for little value. And I _really_ don't like how it
> results in people flipping chains of a(b(c(d(5)))) calls into
> something like d(5).c().b.().a(). I think that it makes the code way
> harder to read. The code is completely backwards. But I appear to be
> in the minority with that opinion. I also don't like how it creates so
> many ways to write exactly the same code. It harms readibility. But as
> much as I dislike many of the applications of UFCS, it _does_ appear
> to be quite popular. And upon occasion, it may be useful, but I _am_
> wishing that we hadn't added it.

Strange, I like it a lot because unifying function calls makes it very
easy to write generic code without sprinkling static ifs everywhere.


[...]
> Overall, I think that D's feature set is fairly solid. It's mostly
> just the implementation of said features which is a problem - though
> some minor tweaks are probably in order (e.g. as Bearophile suggests,
> make it so that adjacent string literals don't concatenate).
[...]

I thought adjacent string lits have been deprecated or no longer
supported? Personally I like it; it lets you format long literals over
multiple lines without needing a ~ in between. And also, recently I
found this annoyance:

	throw new Exception("A very long message (%s) that is "~
		"broken across multiple (%d) lines".format(msg,count));

This doesn't work because ~ has lower precedence than ., so you need
extra parentheses around the strings:

	throw new Exception(("A very long message (%s) that is "~
		"broken across multiple (%d) lines").format(msg,count));

Whereas being able to concatenate adjacent literals would've been this a
lot more readable.


T

-- 
I don't trust computers, I've spent too long programming to think that they can get anything right. -- James Miller


More information about the Digitalmars-d mailing list