On Monday, 22 October 2018 at 09:40:42 UTC, Manu wrote:
> On Mon, Oct 22, 2018 at 2:21 AM ag0aep6g via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>>
>> On 22.10.18 10:39, Simen Kjærås wrote:
>> > On Sunday, 21 October 2018 at 22:03:00 UTC, ag0aep6g wrote:
>> [...]
>> > It's invalid only if Atomic.badboy exists.
>>
>> I don't agree. I prefer the stronger @trusted. As far as I know, the stronger one is the current one.
>
> The current one has the critical weakness that it causes **EVERY USER** to write unsafe code, manually casting things to shared.

Nope:

-------
auto list = /*new?*/ shared MyFancyLockFreeList();
-------

If you want a `shared` something, create it as shared to begin with, there's no need to cast.

On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
> Frankly, this does not sound credible. According to this rationale, array access should be @system too, because it relies on the array not giving direct access to its length to the user, which would also in itself be @safe.

Arrays are a language builtin. As far as I'm aware, there isn't actually an struct defined in DRuntime for arrays. But maybe I'm wrong. If there is, and if it uses a plain size_t for the length member, then it is breaking the strong @trusted promise, yes.

But having existing exceptions to the rule doesn't mean that the rule is void. We could identify the existing exceptions as bugs and try to fix them. Or we could say that they're a necessary evil, but we don't want to add more evil.

On the other hand, D could of course embrace a weaker @trusted/@safe. That would be up to Walter and Andrei, I guess. As far as I can tell from the other `shared` thread, Walter currently favors a strong @trusted.

On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
> Frankly, this does not sound credible. According to this rationale, array access should be @system too, because it relies on the array not giving direct access to its length to the user, which would also in itself be @safe.

For reading, its a size_t so can be done with atomics, writing OTOH is a @property that calls a function to reallocate if ned be. Reallocation obviously needs to be locked.

On Monday, 22 October 2018 at 14:23:09 UTC, ag0aep6g wrote:
> Arrays are a language builtin. As far as I'm aware, there isn't actually an struct defined in DRuntime for arrays. But maybe I'm wrong. If there is, and if it uses a plain size_t for the length member, then it is breaking the strong @trusted promise, yes.

This does not only apply to builtin arrays. It also applies to RAII or refcounted memory resources made safe with DIP1000

> But having existing exceptions to the rule doesn't mean that the rule is void.

Perhaps you're right. But IMO the proposed struct would definitely be low-level and fundamental enough to warrant an exception to that rule.

Note, I'm not saying I support what Manu proposed, just that the argument about strong @trusted should not stop the proposal if we otherwise like it.

On Monday, 22 October 2018 at 14:49:13 UTC, Nicholas Wilson wrote:
> On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
>> [snip]
>
> For reading, its a size_t so can be done with atomics, writing OTOH is a @property that calls a function to reallocate if ned be. Reallocation obviously needs to be locked.

True, but I meant that the very concept of array having a length member violates the strong @trusted rule referred to by the theard author. That's because somebody could make a @safe function to the module defining an array that makes the array unsafe to use (If the array is a struct in DRuntime, that is. I'm not sure about that.).

On 23.10.18 12:23, Dukc wrote:
> This does not only apply to builtin arrays. It also applies to RAII or refcounted memory resources made safe with DIP1000

Absolutely. And they would be (or are) in violation of a strong @trusted.

[...]
> Perhaps you're right. But IMO the proposed struct would definitely be low-level and fundamental enough to warrant an exception to that rule.

Maybe. But then the proposer has to spend time and nerves justifying the exception against fundamentalists like me or the more prestigious Timon Gehr. If marking the fields as `shared` is enough to maintain a strong @trusted, then that's a really simple way of making everyone happy.

> Note, I'm not saying I support what Manu proposed, just that the argument about strong @trusted should not stop the proposal if we otherwise like it.

I guess it comes down to how much value one assigns to a strong @trusted. Myself, I think that a strong @trusted/@safe is really, really nice. And I'd like to think that it can be maintained without any exceptions.

For non-`shared` safety-critical variables (reference count, etc.), there doesn't seem to be a nice solution to the problem, yet. We could mark them with Manu's `shared` just to force a non-@safe cast. But that would be silly, they're not shared in any way.

Instead, maybe we could let @system apply to variables. It would forbid accesses from @safe code. Then (strongly) @trusted code can rely on them.

Without a language change, an idiom like this might do the trick:

----
struct Array(T)
{
    Unsafe!size_t length;
    Unsafe!(T*) ptr;

    ref int opIndex(size_t i) @trusted
    {
        if (i >= length) throw new Error("");
        return ptr[i];
    }
}

struct Unsafe(T)
{
    void[T.sizeof] data;
    ref T get() @system { return * cast(T*) &data; }
    alias get this;
}

@safe unittest
{
    Unsafe!int x;
    int y;
    static assert(!__traits(compiles, x = 42));
    static assert(!__traits(compiles, y = x));
}

@system unittest
{
    Unsafe!int x;
    x = 42;
    assert(x == 42);
    int y = x;
    assert(y == 42);
}
----

On Tuesday, 23 October 2018 at 11:24:27 UTC, ag0aep6g wrote:
> Instead, maybe we could let @system apply to variables. It would forbid accesses from @safe code. Then (strongly) @trusted code can rely on them.
>
> Without a language change, an idiom like this might do the trick:
>
> [snip]

Sounds good.

On Tuesday, 23 October 2018 at 11:24:27 UTC, ag0aep6g wrote:
> [snip]
>
> Instead, maybe we could let @system apply to variables. It would forbid accesses from @safe code. Then (strongly) @trusted code can rely on them.
>
> Without a language change, an idiom like this might do the trick:
> [snip]

We don't need a disruptive, breaking change. @safe currently only applies to functions. Applying to variables is a first step, but ideally you would want it to apply like a UDA to arbitrary scopes as well. That way you can have an @safe part of a function and a @system part of a function and then have the overall thing be @trusted and can easily see which is which. It's really more of a code organization thing than anything else. You could do the same thing now by just breaking apart the function into multiple sub-functions.

On Tue, 23 Oct 2018 10:31:25 +0000, Dukc wrote:

> On Monday, 22 October 2018 at 14:49:13 UTC, Nicholas Wilson wrote:
>> On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
>>> [snip]
>>
>> For reading, its a size_t so can be done with atomics, writing OTOH is a @property that calls a function to reallocate if ned be. Reallocation obviously needs to be locked.
> 
> True, but I meant that the very concept of array having a length member violates the strong @trusted rule referred to by the theard author. That's because somebody could make a @safe function to the module defining an array that makes the array unsafe to use (If the array is a struct in DRuntime, that is. I'm not sure about that.).

Altering the length of a builtin array calls a runtime function _d_arraysetlengthT to reallocate it. And they don't have a .tupleof property. So builtin arrays are safe.

On 23.10.18 17:37, Neia Neutuladh wrote:
> On Tue, 23 Oct 2018 10:31:25 +0000, Dukc wrote:
> 
>> On Monday, 22 October 2018 at 14:49:13 UTC, Nicholas Wilson wrote:
>>> On Monday, 22 October 2018 at 11:24:27 UTC, Dukc wrote:
>>>> [snip]
>>>
>>> For reading, its a size_t so can be done with atomics, writing OTOH is
>>> a @property that calls a function to reallocate if ned be. Reallocation
>>> obviously needs to be locked.
>>
>> True, but I meant that the very concept of array having a length member
>> violates the strong @trusted rule referred to by the theard author.
>> That's because somebody could make a @safe function to the module
>> defining an array that makes the array unsafe to use (If the array is a
>> struct in DRuntime, that is. I'm not sure about that.).
> 
> Altering the length of a builtin array calls a runtime function
> _d_arraysetlengthT to reallocate it. And they don't have a .tupleof
> property. So builtin arrays are safe.
> 

What he is saying is, you could add some @safe code to the druntime module that defines the dynamic array struct. Then, within this code, DMD would consider independent assignments to the length and ptr members @safe, even though this is not the case. Therefore, @safe is broken in druntime.