Origins of the D Programming Language

[H. S. Teoh]

On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via Digitalmars-d wrote:
[...]
> Ugh, purity shouldn't be a default. Purity by default results in a
> monadic joke language, consequences are immense as you can see by the
> haskell example, effectively kills scripting and system programming.

I think you misunderstand the intent here.  Purity by default doesn't
mean everything must be pure with no way out except awkward periphrases
like monads.  It means you opt out of purity by specifying impure,
rather than start with impure and opt into purity by specifying pure.
I.e., an undecorated function will be implicitly pure, but if you want
impure code, you add an `impure` attribute to the function.


> Immutability by default requires shadowing to emulate mutability, so
> isn't without shortcomings, also kills ranges.

Again, the idea here isn't to force everything to be immutable; rather,
it's to make variables immutable by default, but if you want them to be
mutable, you specify them as mutable. Cf. Rust's var/val.


> Safety is still a prototype, too early to deploy it in production.
> Combined they destroy convenience and to an extent performance and
> restrict language to haskell niche, which is nothing to be proud of.

It's true that @safe isn't completely implemented yet (and IMO the
implementation suffers from the inherent incompleteness of using a
blacklist rather than a whitelist), but I think the idea here is again
that functions would be @safe by default, and you can opt out by
specifying @system when you need to.  This would mean @safe checks will
apply by default to general D code, except for the few exceptions when
you need to do something @system. The two can still interface via
@trusted, as they do today.

Basically, the language would pretty much remain the same as it is,
except with some attributes negated by default, i.e., an undecorated
function would be pure @safe, but you can opt out by specifying impure /
@system.  Variables would be immutable by default, but you specify
mutable when they need to mutate.  This would encourage the coder to
write cleaner code, but doesn't stop you from "getting your hands dirty"
with low-level impure/unsafe/etc. code when you need to, e.g. to
implement low-level primitives or squeeze out performance.  (Note also
that by being pure/immutable by default is likely also to afford the
optimizer more opportunities for optimization, so it may not be the
performance hit you seem to think it is, it could be quite the
opposite.)


T

-- 
You have to expect the unexpected. -- RL