July 13

On Tuesday, 13 July 2021 at 22:11:34 UTC, SealabJaster wrote:

>

...

https://github.com/PlummersSoftwareLLC/Primes/pull/407

July 14

On Tuesday, 13 July 2021 at 19:45:48 UTC, ag0aep6g wrote:

>

On Tuesday, 13 July 2021 at 19:06:12 UTC, Bastiaan Veelo wrote:

>
// If not called from multiple threads, this can be trusted.

I.e., it can't be trusted. When a function needs a comment that explains how to call it safely, then it's an @system function.

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.

July 14
On 14.07.21 09:08, Sebastiaan Koppe wrote:
> On Tuesday, 13 July 2021 at 19:45:48 UTC, ag0aep6g wrote:
>> On Tuesday, 13 July 2021 at 19:06:12 UTC, Bastiaan Veelo wrote:
>>>     // If not called from multiple threads, this can be trusted.
>>
>> I.e., it can't be trusted. When a function needs a comment that explains how to call it safely, then it's an @system function.
> 
> 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?

If the function might corrupt memory, it must be @system. This is how I understand the comment.
If the function cannot corrupt memory (even when called from multiple threads), the comment is very misleading.
If the function cannot possibly be called from multiple threads (no idea how that would work), the comment is also misleading.
July 14
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.
July 14

On Wednesday, 14 July 2021 at 19:10:55 UTC, Sebastiaan Koppe wrote:

>

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.

The object isn't necessarily the thing that is being shared. A method can be accessing some __gshared global just like a static function can.

July 15

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.

July 15

On Wednesday, 14 July 2021 at 20:45:05 UTC, ag0aep6g wrote:

>

On Wednesday, 14 July 2021 at 19:10:55 UTC, Sebastiaan Koppe wrote:

>

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.

The object isn't necessarily the thing that is being shared. A method can be accessing some __gshared global just like a static function can.

Of course, there is always a loophole somewhere.

But does that all imply that we have to make all non-threadsafe functions @system? How can we every be @safe?

July 15

On Wednesday, 14 July 2021 at 20:45:05 UTC, ag0aep6g wrote:

>

On Wednesday, 14 July 2021 at 19:10:55 UTC, Sebastiaan Koppe wrote:

>

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.

The object isn't necessarily the thing that is being shared. A method can be accessing some __gshared global just like a static function can.

@safe code can't access __gshared data.

July 15

On Thursday, 15 July 2021 at 12:35:29 UTC, Petar Kirov [ZombineDev] wrote:

>

On Wednesday, 14 July 2021 at 19:10:55 UTC, Sebastiaan Koppe

>

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.

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.

Yes that is the sensible thing to do. But I am not sure that is the right thing. I am afraid that it will lead to the conclusion that everything needs to be shared, because who is going to stop someone from taking your struct/class/function, moving it over to another thread and then complain it corrupts memory while it was advertised as having a @safe interface?

July 15

On Thursday, 15 July 2021 at 13:10:44 UTC, Sebastiaan Koppe wrote:

>

But does that all imply that we have to make all non-threadsafe functions @system? How can we every be @safe?

Write thread-safe code?

1 2 3