Prime sieve language race

[Petar]

On Wednesday, 14 July 2021 at 19:10:55 UTC, Sebastiaan Koppe 
wrote:
> On Wednesday, 14 July 2021 at 12:08:29 UTC, ag0aep6g wrote:
>> On 14.07.21 09:08, Sebastiaan Koppe wrote:
>>> Why can't non-threadsafe functions be @safe? Because it might 
>>> corrupt memory?
>>> 
>>> On a static function that is probably the right thing to do. 
>>> But what about with a member function? I would argue it isn't.
>>
>> You would argue that a function that might corrupt memory 
>> should be @trusted when it's a member function?
>
> Because member functions are harder to call from multiple 
> threads than static functions are. For one, you will have to 
> get the object on two threads first. Most functions that do 
> that require a shared object, which requires a diligent 
> programmer to do the casting.

While in terms of program design, encapsulation is very related 
to safety (as it allows to hide unsafe interfaces that may 
violate program invariants), from a D language point of view, 
they're completely orthogonal concepts.

An argument, can only be made in favor of allowing `@trusted` 
nested functions with non-`@safe` interface (which have the 
strongest form of encapsulation, just by means of lexical 
scoping) when they improve readability considerably compared to 
IIFE (@trusted lambda idiom).

The problem with `std.stdio : std{in,out,err}` is they ought to 
be defined (conceptually) as `shared Atomic!File`, where `File` 
is essentially a wrapper around `SharedPtr!FileState` (and 
`SharedPtr` does atomic ref-counting, if it's `shared`) and until 
then, they shouldn't be `@trusted`, unless the program is 
single-threaded.