does D already have too many language features ?
paultjeadriaanse at gmail.com
Thu Jan 28 15:30:52 UTC 2021
On Thursday, 11 April 2019 at 12:09:10 UTC, Dejan Lekic wrote:
> What I really find as an annoying problem is that almost all D
> features are half-baked...
I'm curious what you mean with half baked.
I'm also surprised people say there's too many features, when I'm
of the opinion several features I'd like, that have been stuck in
DIP hell for like 3 years, would only make the language simpler.
- I consider the disability to use struct initialization inline
as an unexpected limitation.
- I think the way tuples currently work is also confusing, it
requires a lot of looking into aliasSeq & Tuple library stuff.
- Removing the comma operator entirely, as seems suggested in the
tuple DIP, would remove a feature some people might not use, but
it's not a complex concept to understand and thus feels like an
- static if & static foreach seem like nice features, but their
naming is not at all logical. Reuse of the 'static' keyword only
creates confusion. And it's a halfbaked concept too! There is no
static switch, and I can't have a compiletime only piece of code
to work with static if & mixin without creating A LOT of manifest
constants or having to use functions for it. Why have CTFE,
static if/foreach, mixin but not just CT? (Hence my suggestion of
using a ct/comp/compile keyword for static if/foreach & new
compile-time non-constant 'compile' variables)
- I don't know if I'm the only one, but I believe having a
seperate 'manifest' keyword for manifest constants would make
them less confusing.
- The inability to create a non-argument constructor for structs
is one of those edge-cases one doesn't expect and has to make a
workaround for. Why can't we have this?
TLDR; Sorry for the rant, I'm just of the opinion that no, there
are not too many features in D.
Rather the opposite, I'm of the opinion D has a DIP hell problem.
More information about the Digitalmars-d