On Friday, 26 February 2021 at 09:49:40 UTC, Walter Bright wrote:
>     private static struct Slice
>     {
>         private int* ptr;
>         private size_t length;
>
>       @trusted:
>
>         this(int[] src)
>         {
>              ptr = src.ptr;
>              length = src.length;
>         }
>
>         int[] opSlice()
>         {
>              return ptr[0 .. length];
>         }
>      }

This is equivalent to the example in the DIP, except that you have changed the constructor from @safe to @trusted by replacing `&src[0]` with `src.ptr`. If you had written it in the same was as the original, you would still have to manually check @safe code in order to prove that this interface is memory-safe.

On 26.02.21 13:34, Imperatorn wrote:
> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>> This is the discussion thread for the second round of Community Review of DIP 1035, "@system Variables":
>>
>> [...]
> 
> Well done. Everything in the direction of safety if very important to our company. Great work.
Feel free to contribute to what is important to you instead of unproductively trolling discussion threads you do not care about. Thanks.

This is my last post in this subthread.

On Friday, 26 February 2021 at 14:04:45 UTC, Timon Gehr wrote:
> On 26.02.21 13:34, Imperatorn wrote:
>> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>>> This is the discussion thread for the second round of Community Review of DIP 1035, "@system Variables":
>>>
>>> [...]
>> 
>> Well done. Everything in the direction of safety if very important to our company. Great work.
> Feel free to contribute to what is important to you instead of unproductively trolling discussion threads you do not care about. Thanks.
>
> This is my last post in this subthread.

I don't think you understand the definition of trolling unfortunately.

Your behavior is just objectively wierd.
You have no idea what I care about.

If there are something happening in you life that make you socially underperformed or unable to have good manners in general, direct your last watt of energy towards fixing that instead instead of writing in the forums. Thanks.

On 26.02.21 13:34, Imperatorn wrote:
> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>> This is the discussion thread for the second round of Community Review of DIP 1035, "@system Variables":
>>
>> [...]
> 
> Well done. Everything in the direction of safety if very important to our company. Great work.

On 26.02.21 14:04, Imperatorn wrote:
> 
> I don't think you understand the definition of trolling unfortunately.

For some reason I read your original comment as sarcastic. I think I had confused you with another member of the forums who is also posting under a pseudonym. Sorry about that. Mea culpa.

On 26.02.21 14:04, Imperatorn wrote:
> If there are something happening in you life that make you socially underperformed or unable to have good manners in general, [...]

I am sorry for having provoked you into violating basic standards of decency.

On Friday, 26 February 2021 at 15:14:51 UTC, Timon Gehr wrote:
> On 26.02.21 13:34, Imperatorn wrote:
>> On Thursday, 25 February 2021 at 09:21:20 UTC, Mike Parker wrote:
>>> This is the discussion thread for the second round of Community Review of DIP 1035, "@system Variables":
>>>
>>> [...]
>> 
>> Well done. Everything in the direction of safety if very important to our company. Great work.

> For some reason I read your original comment as sarcastic. I think I had confused you with another member of the forums who is also posting under a pseudonym. Sorry about that. Mea culpa.
>

I see. No worries. I actually just wanted to say that it was good work and that we care about that.

Misunderstandings happens sometimes. Peace

On Friday, 26 February 2021 at 09:49:40 UTC, Walter Bright wrote:
> > Example: User-Defined Slice
>
> Since ptr and length are private, they are only accessible to member functions of IntSlice.

Er, doesn't private mean module access? This DIP would help verify long modules that might inadvertently access unsafe fields from outside the struct definition, at least in @safe code.

On Friday, 26 February 2021 at 18:29:26 UTC, Nick Treleaven wrote:
> On Friday, 26 February 2021 at 09:49:40 UTC, Walter Bright wrote:
>> > Example: User-Defined Slice
>>
>> Since ptr and length are private, they are only accessible to member functions of IntSlice.
>
> Er, doesn't private mean module access? This DIP would help verify long modules that might inadvertently access unsafe fields from outside the struct definition, at least in @safe code.

https://run.dlang.io/is/KalIzj

Yes - however code subject to is supposed to be consumed in a different module for the most part, so this could be a nice side effect but it shouldn't (de jure) guide the actual DIP itself.

https://issues.dlang.org/show_bug.cgi?id=21665

A simple workaround is an unsafe wrapper:

struct Unsafe
{
	private T a;
	T get() @system { return a; }
}

struct IntSlice
{
	private Unsafe!(int*) ptr;
	private Unsafe!size_t length;
...

On Saturday, 27 February 2021 at 05:59:23 UTC, Walter Bright wrote:
>
> https://issues.dlang.org/show_bug.cgi?id=21665

Would that be a compiler error or warning ignoring initialization if you tried to void init a struct having invariant?