On 04/04/2024 7:50 AM, Dukc wrote:
> On Saturday, 30 March 2024 at 02:28:02 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> As part of type state analysis work, I've been thinking about whether would we want to keep old ``@safe`` available for new editions to use.
>> I suspect that the answer is yes.
>> Not everyone wants to use DIP1000 or temporal safety.
>>
>> So what I am thinking is also an answer to ``@safe`` by default.
>>
>> Introduce a new level to SafeD, ``@tsafe``, for temporarily safe.
>>
>> Move to disable DIP1000 in ``@safe``.
>> Treat it as ``@trusted + @somelints`` instead.
>>
>> This also answers another question, how do you pass around old ``@safe`` in new editions.
>>
>> The default for all functions with bodies would be ``@tsafe``, if you see any of these four attributes, it indicates review is required.
> 
> Can you please write a code example or two? Doesn't have to be anything with a nailed-down syntax, but it's really hard to be sure what you're suggesting without one.

Okay so you need something a bit bigger picture for temporally safe?

My way of working would mean I would need to solve isolated and then temporally safe before I can do that.

It might be a while before it all comes together for me to be able to do it concretely.

On 05/04/2024 1:32 AM, Dukc wrote:
> On Thursday, 4 April 2024 at 06:45:44 UTC, Richard (Rikki) Andrew Cattermole wrote:
> 
>>> Can you please write a code example or two? Doesn't have to be anything with a nailed-down syntax, but it's really hard to be sure what you're suggesting without one.
>>
>> Okay so you need something a bit bigger picture for temporally safe?
>>
>> My way of working would mean I would need to solve isolated and then temporally safe before I can do that.
>>
>> It might be a while before it all comes together for me to be able to do it concretely.
> 
> I mean, given you're posting this as a new thread in the DIP ideas forum, I'm assuming you have a language improvement idea to present and want some informal feedback for it. But I don't get from your posts what exactly you're proposing, only that it's some sort of improvement to `@safe`.

Okay yes, you want some big picture overview.

Temporal safety is about making sure one thread doesn't stomp all over memory that another thread also knows about.

So this is locking, ensuring only one thread has a reference to it, atomics ext.

Moving us over to this without the edition system would break everyone's code. So it has to be based upon this.

So the question of this thread is all about how do we annotate our code to indicate its temporally safe and how does it map into older editions view of what safe is. There is at least three different solutions to this that I have come up with.

Escape analysis wrt. DIP1000 is only a very small part of such a system. But it all plays together to give us what is known as program security.

Program security is what the CS field has been working towards since the 80's. Its about guaranteeing that a program will work as expected guaranteed. We are no where near that, it'll need a proof assistant for full blown program security, however temporal safety will get us most of the way there.

I know Walter has seen the writing on the wall for PL's if they don't have it ~5 years ago. Hence DIP1000 and @live. However I don't know how far along the path he has gone. I'm waiting on him talking with Adam Wilson this month to find that out to know how to proceed with type state analysis (which is a building block to make it all work nicely together).

On 05/04/2024 7:55 PM, Dom DiSc wrote:
> On Saturday, 30 March 2024 at 02:28:02 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> Introduce a new level to SafeD, ``@tsafe``, for temporarily safe.
> 
> I think every step in direction "@safe by default" is an improvement. But what we need to avoid is generating another attribute that's parallel to the existing @safe.
> 
> If what you suggest is in the same line (@system ⊇ @trusted ⊇ @tsafe ⊇ @safe), so provides the same but not all of the guarantees @safe provides, I'm all for it.
> But if @tsafe is independend from @safe like @life: forget it.

You have @tsafe the wrong way round to @safe.

It would be a stronger guarantee of temporal safety + more basic pointer safety.

@system ⊇ @trusted ⊇ @safe ⊇ @tsafe

The capability to have @safe without DIP1000 what we have now would exist in the compiler, and keeping a way to specify it means we can interact with older code that is @safe.

I considered remapping @safe in newer editions to temporal and having a new attribute or ``@trusted @safe`` to map to the older one but I am concerned it'll result in confusion when looking at different edition code.

On Friday, 5 April 2024 at 07:16:47 UTC, Richard (Rikki) Andrew Cattermole wrote:
> You have @tsafe the wrong way round to @safe.
>
> It would be a stronger guarantee of temporal safety + more basic pointer safety.
>
> @system ⊇ @trusted ⊇ @safe ⊇ @tsafe
>
> The capability to have @safe without DIP1000 what we have now would exist in the compiler, and keeping a way to specify it means we can interact with older code that is @safe.
>

So, you want something even stronger than @safe (requiring DIP1000 compliance) to be the default?
I mean, I would like it. But how do you see the chances this will happen if now we can't even agree to @safe by default?!?

On 05/04/2024 8:23 PM, Dom DiSc wrote:
> On Friday, 5 April 2024 at 07:16:47 UTC, Richard (Rikki) Andrew Cattermole wrote:
>> You have @tsafe the wrong way round to @safe.
>>
>> It would be a stronger guarantee of temporal safety + more basic pointer safety.
>>
>> @system ⊇ @trusted ⊇ @safe ⊇ @tsafe
>>
>> The capability to have @safe without DIP1000 what we have now would exist in the compiler, and keeping a way to specify it means we can interact with older code that is @safe.
>>
> 
> So, you want something even stronger than @safe (requiring DIP1000 compliance) to be the default?
> I mean, I would like it. But how do you see the chances this will happen if now we can't even agree to @safe by default?!?

Escape analysis is needed to perform temporal safety, so yes. It needs to be in that order.

As far as @safe by default is concerned, if a DIP proposed it with the revisions regarding requiring a body, I do expect it to be accepted, although inference is the considered approach currently.

Thanks to the upcoming edition system, we can be a bit bold and consider changing defaults :)