If you could make any changes to D, what would they look like?

[H. S. Teoh]

On Mon, Oct 25, 2021 at 02:34:24PM +0000, IGotD- via Digitalmars-d wrote:
> On Monday, 25 October 2021 at 13:42:19 UTC, Guillaume Piolat wrote:
> > It's a great thing other people get to decide, because I would remove:
[...]
> > - pure
> 
> Agreed, if you don't want a function messing around with a global
> state, don't mess around with a global state, easy. You don't need a
> badge for that. I'm sure there are holes in the pure rule that the
> compiler cannot detect as well.

I think the idea behind pure is for the compiler to enforce purity in
your code, since human beings are prone to making mistakes.  And also to
optimize code in certain cases, though in practice that's so rare that
it's not really that useful (IIRC, the only optimization currently
performed applies only to strongly pure functions, and within a single
expression, so that `f(x) + f(x)` calls `f` only once if f is strongly
pure.

Well, pure is also used in implicit casting to immutable in functions
that construct objects. But this is also relatively rare and somewhat
low impact.

So I'm on the fence about `pure` in D. It promises a lot, but the
current implementation is lackluster, and delivers only a little. If it
had a bigger impact on optimization, say, it could be more useful. But
currently its impact in practice is rather niche, and most of the time
doesn't really affect much in code. (Perhaps except to generate annoying
compile errors when something expects to be pure but isn't!)


> > - shared
> 
> Agreed, shared is one of the biggest mess in D. This is where it is
> obvious where the D language designers lack in experience and
> knowledge. It is also a very complex issue so my advice is to rather
> to copy an existing design or not at all and rely more on manual
> concurrent "safety".

Agreed.


> > - @property
> 
> Do we need it? Isn't this partly handled by UFCS.

@property was incompletely implemented, lacks a clear vision, and
currently is basically just bitrotting.  With UFCS and optional
parentheses, plus some questionable designs (i.e., `a.x = y` is
rewritten as `a.x(y)` under some circumstances), @property is basically
redundant and affects very little. The only concrete case I can think of
where it actually makes a difference is when you have a property
function that returns by ref and the caller tries to take the address.
Well, that and isInputRange stubbornly insists on @property even though
it technically doesn't need to.

So yeah, niche use, incomplete implementation, low impact.  Meh.
Wouldn't miss it if it went the way of the dodo.


> > - inout
> 
> Isn't this depreciated?

Not that I know of.  And yeah, it's a mess. Very convenient in the
simple cases, a nightmare to work with in non-trivial cases due to
complicated interactions with the rest of the type system and incomplete
functionality in that area.


> > - GC-calling-destructors
> 
> GC calling destructors is often not used. However, there might be rare
> occasions we need it. Like knowing when something is being destroyed.

GC and dtors are just bad news in general... unless you don't care when
something is destroyed (if ever), just that fact that it was destroyed.


> > - virtual-by-default
> 
> Agreed, it should be final by default. This one of the rare occasions
> where the D maintainers agree.

Unfortunately this can't be changed without subtle breakage of a whole
ton o' code.  So, sadly, not gonna happen.


> > - real
> 
> Agreed, real can be removed. Even Intel doesn't optimize their old FPU
> anymore and SSE is used instead. There might be rare occasions where
> we should use old Intel FPU, like embedded Pentium clones but these
> are rare themselves.

Real is nice in those rare circumstances where (1) the extra precision
actually make a difference, and (2) the performance hit doesn't kill
you.  But yeah, it's not the best thing there is.  Part of the problem
is how std.math greedily converts to real and back (though IIRC this has
been (partially?) fixed in recent releases).

Also, it's the one type in D that doesn't have a fixed width, which can
lead to surprising results in cross-platform code (though, admittedly,
only rarely).


> > - synchronized
> 
> I kind of like the idea with synchronized classes. I don't think it is
> that hard to implement and could be a neat thing. Also helps Java
> portability.

It's convenient for quick-n-dirty concurrent OO code where performance
isn't critical. But if you want more modern concurrent techniques / high
performance, yeah, it's not of much use.  It's arguably dated
technology.


> > - alias this
> 
> Agreed, alias this should be removed and mixin templates should be
> used instead.
[...]

`alias this` is awesome for refactoring code, though. When you want to
substitute a new type for an existing one and want code that expect only
the old type to work without a truckload of rewriting.

But yeah, beyond a rather narrow scope of usefulness, it quickly leads
to poor maintainability and other code smells.


T

-- 
Дерево держится корнями, а человек - друзьями.