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

[Adam D. Ruppe]

On Tuesday, 16 April 2019 at 05:44:22 UTC, Eugene Wissner wrote:
> I began to write again some JS and PHP and wondered first "How 
> can I write programs without pure?". And now I would say it 
> isn't bad at all without it.

Yeah, pure definitely isn't a must-have, but I also think it is 
kinda nice... as long as the little leaf functions are easy, and 
IMO that is where the default shines.

My example is a property getter:

pure nothrow @safe const @nogc
int a() { return a_; }

When the attribute list is longer than the function, I just think 
that is silly.

> But if there is no way around pure, I would say yes, pure by 
> default would be reasonable even if I would prefer 
> "@pure(false)/@pure(true)".

So a point I have thought of recently: we also need `null` in 
addition to true and false there. This acts as if the attribute 
was never given. Why?


@safe:

/* snip a lot of stuff */

T map(alias fn, T)(T[]) {}


That map template right now is considered safe, because of the 
colon above. This means it MUST also call a @safe fn. But 
templates are usually more flexible; it will infer the safety 
based on the `fn` sent to it.

With @safe, we can turn it off with its opposites...

@system T map....

(or @safe(false) same thing)

But this means it can no longer be called by @safe functions! 
Still not the same result as just leaving the attribute off.


Hence my proposal:

@safe(null) T map...


The null there just erases any matching attribute that was 
inherited from a group above, allowing the compiler to revert to 
the default - which for templates, is actually inference.