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?

Thanks,
Mike

On 16/04/2019 3:59 PM, Mike Franklin 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.

Can you please give us a quick overview of what you're thinking of? Its a subject that has been thought about in the past with not much success.

On Tuesday, 16 April 2019 at 04:20:56 UTC, rikki cattermole wrote:

> Can you please give us a quick overview of what you're thinking of? Its a subject that has been thought about in the past with not much success.

In order for me to articulate it correctly and completely, I'd have to basically write the DIP in this forum thread.  I'm not prepared to do that at this time.  As I said, I still need to think it through, even for myself.  I'd prefer to leave that discussion for the DIP review.

At the moment, I just need to know if, for the benefit of D in the long term, we want `pure` and/or `immutable` by default so I can clarify the scope of the DIP.

Thanks,
Mike

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin 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?
>
> Thanks,
> Mike

immutable by default would be good if D wasn't a systems programming language. Immutability plays nice with a GC, but even with a GC it probably requires a different one which is more efficient with immutable data and I'm not sure we can have one, because we have still to support pointers, pointer arithmetic and similar stuff that can break garbage collection.

On the other hand what Phobos/D assumes that some things are mutable. What happens if I say:

auto range = map!(a => a )([1, 2, 3]);

Will it return an immutable range I can't work with?

Immutability shouldn't be default at least as long as there isn't something like __mutable or _metadata or head const for custom types.

As for pure, I think it would be better to just remove it instead of making it default. A year ago, after my first years with a lot of D, I was totally crazy about pure. But after that time 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.

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)".

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin 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.
>
+1

> `@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?
>
I honestly think that data should be implicitly mutable. Data is naturally mutable
and it should be left upon the user to decide about immutability. Look at rust, it has `immutable` data by default but it offers a mechanism of rebinding immutable variables, so you may have something like this:

let x = 5;
.....
500 lines of code later
.....
println!("{}", x);   // 5 or something else?

You know that x is `immutable` but in those 500 lines of code you could always rebind x to another variable by doing `let x = 10`. This, in opinion, breaks the spirit of immutability where you know that once you see a variable initialized
it will never be changed (in @safe code).

As for `pure`, as long as we don't have the equivalent of `not pure`, I don't see how it can be the default

> Can anyone save me some trouble and articulate why it would be bad to have `pure` and/or `immutable` by default?
>
> Thanks,
> Mike

Cheers,
RazvanN

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin wrote:
>
> Can anyone save me some trouble and articulate why it would be bad to have `pure` and/or `immutable` by default?

Immutable by default may be ok for Haskell (I haven't tried), but sounds terrible for D, or most of the perfectly good programs anyone may have written or will write in the future in any language.

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin wrote:
> Can anyone save me some trouble and articulate why it would be bad to have `pure` and/or `immutable` by default?

Among other things immutable by default needs shadowing to reduce namespace pollution. Pure is good for some leaf functions, but is not workable in general case, also needs usual haskell-style purity infrastructure like IO monad, and likely succinct currying and lazy evaluation. Imagine refactoring if something deep suddenly needs to do IO - the usual problem for pure languages.

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin wrote:
> Can anyone save me some trouble and articulate why it would be bad to have `pure` and/or `immutable` by default?

One downside for functions in libraries: authors are more likely to break ABIs by switching an exported function from pure to impure if pure is the default (as opposed to the current opt-in).

https://theartofmachinery.com/2016/10/05/function_attributes_and_d_abi.html

By the way, your DIP would need a spec for un-applying attributes like pure.  That functionality would fill a big gap by itself.

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin 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?
>
> Thanks,
> Mike

I think that `@safe` and `pure` should be the default, but not `immutable`. It's too restrictive. I'd make it `const` by default. I'm not *too* bothere about it though, because I have to write something before the variable's name to declare it anyway, so I myself just default to writing `const` instead of `auto`. The exception in nearly every case that isn't dealing with a dependency that isn't const-correct is ranges.

As mentioned elsewhere on this thread, for `pure` to be the default we need to be able to negate it.

On Tuesday, 16 April 2019 at 03:59:38 UTC, Mike Franklin wrote:
> `@safe` by default is a no-brainer in my opinion, but `pure` and `immutable` by default are less obvious.

I think pure should be too (and actually, even nothrow maybe), but not immutable.

With pure, you won't even actually notice it with the majority of functions... and if you do notice it, you can mostly just change a global to a function argument and solve it, which tends to be cleaner design anyway.

Though, one surprising problem with pure is that floating point functions don't count! We need to think up some solution to that.


immutable though is really a completely different paradigm. It is very invasive, there's no escape hatch (like with nothrow, you can put try/catch on to limit its influence, immutable has no way to get out), and I'd be surprised if any existing D code would work with that change; you'd definitely notice it.

We brag about having pure and mutable together, I like having that.