Origins of the D Programming Language

[H. S. Teoh]

On Sat, Dec 01, 2018 at 05:32:44PM +0000, Paolo Invernizzi via Digitalmars-d wrote:
> On Saturday, 1 December 2018 at 16:07:28 UTC, H. S. Teoh wrote:
> > On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via Digitalmars-d
> > wrote: [...]
> > > [...]
> > 
> > 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.
> > 
> > [...]
> 
> And maybe, class methods final by default?
[...]

This one is a toss-up.  Based on Walter's airplane design philosophy,
the idea is to make the default behaviour the correct / good one, and
require effort to write incorrect / bad code.  Purity by default is good
because pure code has no side-effects, which makes it easier to reason
about (and in some cases, easier for the optimizer to optimize).
Immutable by default is good because it provides more optimization
opportunities (if something doesn't need to change, it shouldn't be
mutable, then the optimizer can eliminate redundant loads where it would
otherwise be unsure whether intervening code may have changed the
original value, if it was mutable), and also prevents common errors like
accidentally changing a value that's not expected to change, or code
smells like reusing variables for something completely unrelated to the
original use.

But for class methods, it's less clear what's the better default.
Especially in D, where structs and compile-time template polymorphism
tend to be preferred where possible, and it almost feels like the raison
d'etre of classes is OO-style runtime polymorphism, so it would make
sense for methods to be virtual by default. OTOH, making them final by
default would also mean you don't incur runtime costs except when you
explicitly ask for virtual.  But then you'd have to specify virtual
everywhere in a construct that seems to be intended precisely for such a
use in the first place. So I'm tempted to say virtual by default makes
more sense (code correctness / clarity / less boilerplate come first,
performance comes later), but I can see how it can be argued both ways.


T

-- 
Do not reason with the unreasonable; you lose by definition.