Origins of the D Programming Language

[Paolo Invernizzi]

On Saturday, 1 December 2018 at 18:28:14 UTC, H. S. Teoh wrote:
> 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

"virtual is a one-way trip. It can't be undone without risking 
breaking
code once released to the wild. How can that state be a sensible 
default?"
(Cit. Manu)

Some years ago, that was debated for long time, and final by 
default was almost landed into D, with the approval of both 
W&A.[1][2], see rationale here [3]

I dare to say that this specific episode was the beginning of all 
the "break/non break" code debate [4] that still persist, and 
that I hope we will tame in the next future...

/P

[1] https://forum.dlang.org/post/koo65g$1nqs$2@digitalmars.com
[2] https://forum.dlang.org/post/koqkhc$4nn$1@digitalmars.com
[3] https://www.artima.com/intv/nonvirtualP.html
[4] https://forum.dlang.org/post/lfqoan$5qq$1@digitalmars.com