`@safe` by default. What about `@pure` and `immutable` by default?

[Jonathan M Davis]

On Monday, April 15, 2019 9:59:38 PM MDT Mike Franklin via Digitalmars-d 
wrote:
> I think I may have found a simple migration path to @safe by
> default.  I'm still thinking it through, but if I can justify it,
> I will write a DIP.
>
> `@safe` by default is a no-brainer in my opinion, but `pure` and
> `immutable` by default are less obvious.  With the aforementioned
> potential DIP, I have an opportunity to correct purity and
> mutability defaults as well...but is that something we want to do?
>
> Can anyone save me some trouble and articulate why it would be
> bad to have `pure` and/or `immutable` by default?

pure can be nice when it works, but really basic things like I/O don't work
if pure is used. You can get around that for debugging with debug blocks,
but if you have a bunch of code, and it turns out that you need to do
something in it that isn't pure, you'd be screwed unless you go and mark a
ton of code with impure (or whatever the opposite of pure would be). It's
not like you can just opt-out in the middle like you can with @safe by using
@trusted to use @system code.

Similarly, you can't opt-out of immutable in the middle of a complex type.
It's transitive. So, having immutable be the default would cause a lot of
problems in aggregate types.

Also, immutable is very much at odds with basic D concepts like ranges. With
how they're currently designed, they require mutability. If immutable were
the default, you'd have to slap mutable _everywhere_.

immutable and pure both work great in very functional code, but they don't
work anywhere near as well in imperative code. And they're particularly bad
if you're doing low level stuff. They're the sort of thing that functional
languages force on you. D is multiparadigm. I would absolutely hate to have
the language effectively try to force everything to be functional and make
you opt-out all over the place. The fact that we have immutable and pure
allow for useful things in the cases where they make a lot of sense, and you
don't need mutability, and you don't need stuff like I/O. I strongly dispute
the idea that your average program is written that way or that that's how
most programmers are going to want to write their code.

Walter and Andrei have talked before about how the attributes are supposed
to be for larger programs where they bring enough benefit to be worth the
trouble. And stuff like smaller scripts shouldn't need to worry about it. I
don't think that there's any question that attributes like pure and
immutable do not fit well in most smaller programs, and if they were the
default, any basic scripts written in D would have to opt-out of them all
over the place.

@safe has some of the same problems, but it's more flexible, and it's far
more reasonable that most code be @safe, since ultimately you want the
top-level of all programs to be @safe, and if the higher level constructs
that are typically going to be used by smaller programs are @safe, then
making @safe the default might be fine. So, I don't know that it's a bad
idea to make @safe the default (though Walter and Andrei have been opposed
to it before, because they thought that it wasn't appropriate to require
that smaller programs worry about it). But I do think that it would a
terrible idea to make pure, immutable, or any other attribute that is not
currently the default the default. IMHO, @safe is the only that even might
make sense. The various attributes are just too restrictive for it to make
sense for them to be the default.

- Jonathan M Davis