On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:
> Interestingly enough if we simple disable semantic check for transitive qualifiers relegating them to pure annotations to be

I've actually thought about making a `-betterD` switch that disables most the annotations, turning them to no-ops.

But your first sentence:

> Make no mistake - thread-local by default is great!

Gonna go ahead and disagree with that, the thread local by default I think is a mistake now. It causes as many problems as it solves.

I'd suggest just making all the global variables need explicit designation of shared or thread local.

> Unlike transitive const, shallow const (~ Java’s final)

You might recall that D used to have that back in the day!

On Tuesday, 11 April 2023 at 13:08:33 UTC, Adam D Ruppe wrote:
> On Tuesday, 11 April 2023 at 12:21:01 UTC, Dmitry Olshansky wrote:
>> Interestingly enough if we simple disable semantic check for transitive qualifiers relegating them to pure annotations to be
>
> I've actually thought about making a `-betterD` switch that disables most the annotations, turning them to no-ops.
>
> But your first sentence:
>
>> Make no mistake - thread-local by default is great!
>
> Gonna go ahead and disagree with that, the thread local by default I think is a mistake now. It causes as many problems as it solves.

If needed we may introduce __threadlocal, what should be the default is a question of compatibility with current D2.
>
> I'd suggest just making all the global variables need explicit designation of shared or thread local.
>
>> Unlike transitive const, shallow const (~ Java’s final)
>
> You might recall that D used to have that back in the day!

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.

On 4/11/23 18:43, Timon Gehr wrote:
> 
> - 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 guess initialization of such data structures will be a bit annoying as `immutable` as a non-transitive storage class kills pure factory functions.

On 4/11/23 18:43, Timon Gehr wrote:
> 
> - 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.

It's not so clear how this would interact with `immutable`.

I guess another complication absent from Scala is that D has structs.

On Tuesday, 11 April 2023 at 16:47:05 UTC, Timon Gehr wrote:
> On 4/11/23 18:43, Timon Gehr wrote:
>> 
>> - 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 guess initialization of such data structures will be a bit annoying as `immutable` as a non-transitive storage class kills pure factory functions.

That much is true. What I have in mind is to reconcile pure functions and CTFE-ability. It would seem that any pure function could CTFE-ed.

On Tuesday, 11 April 2023 at 16:43:08 UTC, Timon Gehr wrote:
> On 4/11/23 14:21, Dmitry Olshansky wrote:
>> [...]
>
> - 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.

As a transitory period we could keep transitive qualifier machinery in place under a flag, then run it as lint and if string stays immutable(char)[] you’d get an error trying to modify its elements. Just a thought.

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

Need to read his proposal.

—
Dmitry Olshansky