D1.5 anyone?

[Dmitry Olshansky]

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