D1.5 anyone?

[Timon Gehr]

On 4/11/23 14:21, Dmitry Olshansky wrote:
> I've often see people clamoring for D3 to set things right. But me I 
> want D1.5, I want to return to that simple and beautiful language that 
> was designed by Walter Bright.
> 
> Interestingly enough if we simple disable semantic check for transitive 
> qualifiers relegating them to pure annotations to be used by lint tool 
> we can get to basically where D1 was in 2007. Why picking on transitive 
> qualifiers, I explain in a new blog post here:
> https://olshansky.me/posts/d-biggest-mistake/
> 
> Thoughts? I'm going to do D1.5 for myself but wanted to know if anyone 
> feels the same.
> ...

Some of mine:

- I am in favor of exploring this idea. It's certainly better than what 
we have now.

- 'val'/'var' is terrible terminology for talking about mutability.

- The most salient things about functional programming are that 
variables hold values and functions are deterministic. Lack of 
mutability is not really fundamental. Ownership and move semantics can 
give you mutable value types even in a purely functional programming 
language and those are pretty useful as well, as they can be passed 
between threads almost as easily as immutable data. (It's a special case 
of `isolated`.) This is something to keep in mind as it's not really 
available in Scala.

- I think it is right that mutability/ownership is naturally a storage 
class and not really a type qualifier. You don't change what you have, 
just how you access it. (It's also what we have been doing for "const" 
in Silq.) However, you may still want to parameterize a type by a 
storage class.

- A story for how this affects built-in types is still somewhat absent. 
I quite like the ergonomics of types like `immutable(char)[]` and 
`immutable(ubyte)[]`, I would be sad to see them go. However, also here, 
it's not naturally the element type that is modified by the qualifier, 
it's more naturally the array type that is modified, here in a somewhat 
hacky way based on the qualifiers on the element type.

- Immutability by interface is already the best way to do immutability 
in a single-threaded environment, for multithreading probably an 
`immutable` storage class can be helpful.

- I feel like the story for multithreading in your post is currently 
almost the least fleshed-out part of it, but maybe something can be 
designed here. Manu has been in favor of allowing things to implicitly 
cast to `shared`. With transitive qualifiers this just cannot be safe, 
but with what you propose I think we can make his vision work. There 
would still need to be some transitive-ish enforcement. Basically, by 
default you should not be able to access an un`shared` field of a shared 
variable. With shared as a storage class, you can actually make 
variables shared temporarily in a safe manner, exactly in the way that 
Manu imagined for his safe parallel foreach.