This is the discussion thread for the Final Review of DIP 1035, "@system Variables":

https://github.com/dlang/DIPs/blob/4d73e17901a3a620bf59a2a5bfb8c433069c5f52/DIPs/DIP1035.md

The review period will end at 11:59 PM ET on March 5, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits, etc.

However, if you have any specific feedback on how to improve the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

And my blog post on the difference between the Discussion and Feedback threads:

https://dlang.org/blog/2020/01/26/dip-reviews-discussion-vs-feedback/

Please stay on topic here. I will delete posts that are completely off-topic.

On Saturday, 19 February 2022 at 12:24:04 UTC, Mike Parker wrote:

The feedback thread is located here:

https://forum.dlang.org/post/kwabfusqvczenjjacbmq@forum.dlang.org

On Saturday, 19 February 2022 at 12:24:04 UTC, Mike Parker wrote:

While this DIP will solve most of the issues of @safe __traits(getMember, xxx, yyy) fetching private members, there is one thing that will remain a problem: destructors.

The issue is that we want a way to specify a destructor so that it could be called by @safe code at end of the lifetime of an instance, but not early:

auto shouldBeSafe()
{ ObjectWithDestructor x;
}

auto shouldBeSystem()
{ ObjectWithDestructor x;
  __traits(getMember, x, "__dtor")();
}

For that to work, we will either have to make privacy inviolable from @safe (the destructor that does not want to be called early would be private, and object.destroy would be changed to be @system for private destructors), or add some alternative way to define destructors.

Why we want to do that at all? DIP1000. Most of the potential of DIP1000 is wasted if you cannot prevent destruction before end of the scope:

@safe void abuse()
{ auto cont = SomeRaiiContainer([1,2,3]);
  scope ptr = &cont.front;
  destroy(cont);
  int oops = *ptr;
}

Yes, you can prevent that by also marking abuse @live. But I think we ought to do better than that. As I see it, @live is mainly meant as a partial memory safety mechanishm for low-level code that cannot be @safe. It isn't intended that you start to mark your average @safe code as @live, that would be terribly onerous. So we don't want to settle for our libraries being memory safe in @live, if we can make them memory safe in normal @safe.

This is not intended as an argument against DIP1035, in fact I'm still in favour of it. I just wanted to point out that it does not entirely solve the problem of __traits(getMember, xxx, yyy) bypassing privacy.

On Sunday, 20 February 2022 at 15:16:30 UTC, Dukc wrote:

Yes, there's an issue for that: Issue 21981 - Manually calling a __dtor can violate memory safety

On Saturday, 19 February 2022 at 12:24:04 UTC, Mike Parker wrote:

In the "Example: int as pointer" section, the following sentence appears:

This sentence correctly recognizes that (absent incorrect @trusted code elsewhere) there is no memory-safety risk in allowing a value without indirections to escape from a function.

It also completely undermines the example's motivation. If there is no benefit to memory-safety from applying scope checking to data without indirections, then there is no justification for enabling such checks in all @safe code, even if they may occasionally be "desirable" for other, non-memory-safety-related reasons.

Later, in the "Description" section, we find the following sentence:

The only justification for this appears to be the example discussed above.

Both this sentence, and the example that attempts to support it, should be removed from the DIP.

On Monday, 21 February 2022 at 19:49:58 UTC, Paul Backus wrote:

This should have been in the Feedback thread. I've reposted it there now:

https://forum.dlang.org/post/lmmpuyeurzavwqiylwlp@forum.dlang.org

On Monday, 21 February 2022 at 19:49:58 UTC, Paul Backus wrote:

It is memory-safety related, it allows you to create custom pointer types. A pointer is just an integer under the hood, the idea of indirections and lifetimes is just a compile time idea around a size_t which indexes into memory. Why can't we do the same with a ushort which indexes into an array?

On Monday, 21 February 2022 at 20:30:07 UTC, Dennis wrote:

If the goal is being able to define custom pointer types, then the DIP should use that as an example instead of talking about file descriptors, and it should explain exactly which part of the example depends on this feature for memory safety (as the other examples do).

I still don't think it's a compelling use-case, though. TailUnqual does something very similar, using the union workaround, and it would not benefit from having access to scope-checked integers because (a) it stores a size_t, so eliminating the union wouldn't save any space; and (b) it needs the union for correct GC scanning regardless.

On Monday, 21 February 2022 at 21:50:31 UTC, Paul Backus wrote:

A double fclose on a FILE* is basically a double free. I thought the same would apply to raw file descriptors, but I just read that a double close simply results in an EBADF error, so maybe it's not a good example.

Yes, TailUnqual doesn't need scope-checked integers, but that doesn't mean other code doesn't need it. I added the rule for two reasons:

• The compiler currently has a notion of a type that hasPointers. The extra complexity of adding a notion hasSystemVariables was daunting, but then I thought we could just make them the same. I think that would not only simplify the implementation, but also the feature in general. It makes it easy to draw a parallel to a pointer and a @system size_t.
• Some people asked for the feature (see links in the rationale section)

I can improve the DIP text, but I'm not yet convinced the rule should be scrapped.

On Monday, 21 February 2022 at 22:56:30 UTC, Dennis wrote:

The compiler needs at least two notions: hasPointers and hasUnsafeValues. hasUnsafeValues is a superset of hasPointers, and also includes aggregate types with @system fields and bool.

Since I assume you do not intend to expand scope checking to bool, folding everything into a single concept will not be possible.

I've read those links. In one of them, the problem was solved using existing DIP 1000 features. The other asks for "unique references (and borrow) to plain ints". It is not clear to me that scope checking for integers would solve either of these problems. If you believe it would, then it should not be difficult for you to write up an example demonstrating how.