On Thursday, 6 June 2024 at 16:59:27 UTC, Timon Gehr wrote:
> On 6/2/24 02:39, Steven Schveighoffer wrote:
>>> - How do function interfaces work when some type annotations exist in only either the language edition of the caller or the language edition of the callee? E.g. think DIP1000 is in one edition but not in another.
>> 
>> The type annotations are defined by the language edition for the imported module. So those would be in effect.
>> 
>> In other words, this is not like today where you compile one module with dip1000 and another module without, and the compiler blindly assumes all are compiled the same way.
>> 
>> This does introduce an interesting wrinkle -- if there are differences, newer editions *must define* the interactions like this between editions as part of the release.
>> 
>> -Steve
>
> Should be in the DIP.

I just tried to put it in the DIP but I'm not sure what the wording should be.

On 20/12/2024 5:52 AM, Atila Neves wrote:
> We can add a compiler switch similar to |-mv| in the future if needed. I'm not sure it needs to go in the DIP.

The problem with -mv is you need the module name. This is awful for build managers, it is awful to the compiler, it is awful to the user.

My current plan is for a edition prefix switch. That should work for everyone. But we'll see what transpires once its time for either myself or somebody else to implement them.

On Thursday, 19 December 2024 at 16:52:35 UTC, Atila Neves wrote:
> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:

>> E.g., there are bugs that allow you to mutate through `const` pointers. Some of them may not be fixed in edition 2024 because the fix would break code. However, in edition 2025 the bugs are fixed. Now edition 2025 calls into a function from edition 2024 that violates memory safety by modifying a const pointer. All involved code is `@safe`, yet memory safety is violated and this hole can never be fixed if edition 2025 can just call into edition 2024.

> I think we will just have to live with this and encourage people to upgrade to the newer edition.

So using a library from a previous edition *could* invalidate memory safety guarantees, and nothing can be done?

This is (again) a marketing disaster ...

On 21/12/2024 2:43 AM, Paolo Invernizzi wrote:
> On Thursday, 19 December 2024 at 16:52:35 UTC, Atila Neves wrote:
>> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
> 
>>> E.g., there are bugs that allow you to mutate through `const` pointers. Some of them may not be fixed in edition 2024 because the fix would break code. However, in edition 2025 the bugs are fixed. Now edition 2025 calls into a function from edition 2024 that violates memory safety by modifying a const pointer. All involved code is `@safe`, yet memory safety is violated and this hole can never be fixed if edition 2025 can just call into edition 2024.
> 
>> I think we will just have to live with this and encourage people to upgrade to the newer edition.
> 
> So using a library from a previous edition *could* invalidate memory safety guarantees, and nothing can be done?
> 
> This is (again) a marketing disaster ...

The solution I came up with that works for both escape analysis and type state analysis, is to treat the old ``@safe`` code as ``@trusted``, so it all gets inferred to make guarantees in new edition, but without any of the errors to allow for old behavior to continue.

If there is need, I guess we can limit calling old ``@safe`` code dependent upon the arguments passed in. However that would be a case by case solution, not something that needs to be dealt with here.

So I don't see how this is a marketing disaster, it can be dealt with if needed and where it can't, it is your responsibility like it is with ``@trusted`` in newest edition.

After all, ``@safe`` does not guarantee program security, it is going to have holes in it and some things are left to you.

On Friday, 20 December 2024 at 16:12:37 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 21/12/2024 2:43 AM, Paolo Invernizzi wrote:
>> On Thursday, 19 December 2024 at 16:52:35 UTC, Atila Neves wrote:
>>> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
>> 
>>>> E.g., there are bugs that allow you to mutate through `const` pointers. Some of them may not be fixed in edition 2024 because the fix would break code. However, in edition 2025 the bugs are fixed. Now edition 2025 calls into a function from edition 2024 that violates memory safety by modifying a const pointer. All involved code is `@safe`, yet memory safety is violated and this hole can never be fixed if edition 2025 can just call into edition 2024.
>> 
>>> I think we will just have to live with this and encourage people to upgrade to the newer edition.
>> 
>> So using a library from a previous edition *could* invalidate memory safety guarantees, and nothing can be done?
>> 
>> This is (again) a marketing disaster ...
>
> The solution I came up with that works for both escape analysis and type state analysis, is to treat the old ``@safe`` code as ``@trusted``, so it all gets inferred to make guarantees in new edition, but without any of the errors to allow for old behavior to continue.

So the @safe documentation section will be "If you want memory safety and you want to use library from a previous editions, you need to review all functions marked @safe in that library"?

> If there is need, I guess we can limit calling old ``@safe`` code dependent upon the arguments passed in.

You mean compiler arguments?

> However that would be a case by case solution, not something that needs to be dealt with here.

The whole point in @safe is _mechanical_ check for safety, for _all_ code marked @safe.
Editions are breaking that, I don't understand how this is not needed to be dealt with here.

> So I don't see how this is a marketing disaster, it can be dealt with if needed and where it can't, it is your responsibility like it is with ``@trusted`` in newest edition.

I think that telling people that code marked @safe really means @trusted sometimes is a marketing disaster, but well, it's an opinion.

> After all, ``@safe`` does not guarantee program security, it is going to have holes in it and some things are left to you.

The whole point in @safe is to guarantee memory security with mechanical check. There's no other selling point for that. Holes are bugs, and are closed from times to times.

I think it's better to simply toss errors when compiling previous editions @safe functions if a hole was closed in the current, and not to leave the programmer clueless if there are some holes in the library it's using. IMHO, of course.

/P

On Thursday, 19 December 2024 at 16:53:41 UTC, Atila Neves wrote:
> On Thursday, 6 June 2024 at 16:59:27 UTC, Timon Gehr wrote:
>> On 6/2/24 02:39, Steven Schveighoffer wrote:
>>>> - How do function interfaces work when some type annotations exist in only either the language edition of the caller or the language edition of the callee? E.g. think DIP1000 is in one edition but not in another.
>>> 
>>> The type annotations are defined by the language edition for the imported module. So those would be in effect.
>>> 
>>> In other words, this is not like today where you compile one module with dip1000 and another module without, and the compiler blindly assumes all are compiled the same way.
>>> 
>>> This does introduce an interesting wrinkle -- if there are differences, newer editions *must define* the interactions like this between editions as part of the release.
>>> 
>>> -Steve
>>
>> Should be in the DIP.
>
> I just tried to put it in the DIP but I'm not sure what the wording should be.

Just wanted to share here this discussion on editions in Rust that I listened to:
https://softwareengineeringdaily.com/2024/10/23/rust-vs-c-with-steve-klabnik-herb-sutter/

At ~35:10 to 41:41 minute mark Herb Sutter asks specifically about editions and applying what Rust has to C++. He asks some stuff about fundamental changes (e.g. changing private to public defaults) and what is and is not possible.

Apparently Rust is doing editions through the intermediate representation in their edition mechanism (This seems to be 'per project' instead of 'per module' as I understand this DIP.).

The Rust strategy seems to answer some of the question of what happens when libraries change, and how to ultimately get code to talk (and again, focusing on just a 'per project' level and having one single Rust compiler seems to make this a lot easier). Ultimately the Rust standard library seems to have 1 'edition' however, which I imagine does not increment its edition frequently.

Anyway, just wanted to share, as that helped frame my understanding of editions.

On Friday, 20 December 2024 at 13:43:40 UTC, Paolo Invernizzi wrote:
> On Thursday, 19 December 2024 at 16:52:35 UTC, Atila Neves wrote:
>> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
>
>>> [...]
>
>> I think we will just have to live with this and encourage people to upgrade to the newer edition.
>
> So using a library from a previous edition *could* invalidate memory safety guarantees, and nothing can be done?
>
> This is (again) a marketing disaster ...

I'm all ears as to what we could do instead.

On Friday, 20 December 2024 at 19:29:26 UTC, Mike Shah wrote:
> On Thursday, 19 December 2024 at 16:53:41 UTC, Atila Neves wrote:
>> [...]
>
> Just wanted to share here this discussion on editions in Rust that I listened to:
> https://softwareengineeringdaily.com/2024/10/23/rust-vs-c-with-steve-klabnik-herb-sutter/
>
> [...]

Nice, thanks for sharing!

On 12/19/24 17:52, Atila Neves wrote:
> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
>> On 6/3/24 18:05, Atila Neves wrote:
>>> On Saturday, 1 June 2024 at 21:14:38 UTC, Timon Gehr wrote:
>>>> [...]
>>>
>>> If they all have module declarations, it's handled there, otherwise I hadn't thought of that. Do you think that will be common? I'm not sure it will be.
>>> ...
>>
>> A lot of code will be written against the default edition and then abandoned at some point.
> 
> We can add a compiler switch similar to `-mv` in the future if needed. I'm not sure it needs to go in the DIP.
> ...

Maybe not, though I anticipate I will need this.

>>>> [...]
>>>
>>> Good question. I guess we'll need some kind of `version(Edition2024)`.
>>> ...
>>
>> Something like that, but `version` only includes one of the symbols, while here we would need to compile all of them.
> 
> Why do we need to compile all of them? Do we need something like `__traits(callerEdition)` maybe?
> ...

It may not be known at library compile time what edition the user will be using, and there may be multiple different users on different editions.

>>>> [...]
>>>
>>> I think I'd need a concrete example.
>>> ...
>>
>> E.g., there are bugs that allow you to mutate through `const` pointers. Some of them may not be fixed in edition 2024 because the fix would break code. However, in edition 2025 the bugs are fixed. Now edition 2025 calls into a function from edition 2024 that violates memory safety by modifying a const pointer. All involved code is `@safe`, yet memory safety is violated and this hole can never be fixed if edition 2025 can just call into edition 2024.
> 
> I think we will just have to live with this and encourage people to upgrade to the newer edition.
> ...

Maybe, though it does invalidate memory safety guarantees. Another way to deal with it is to require something like `@trusted import` for such modules or to otherwise treat all `@safe` imports from that module as `@system`.

>>>> [...]
>>>
>>> The semantics of the edition of the callee apply.
> 
>> This might not work because annotations in a parameter list may require caller-side guarantees in order to be checked.
> 
> Maybe there will be changes we won't be able to make.
> 

Maybe, though I think one thing that will often work is to make such calls `@system`.

On Monday, 23 December 2024 at 16:05:20 UTC, Atila Neves wrote:
> On Friday, 20 December 2024 at 13:43:40 UTC, Paolo Invernizzi wrote:
>> On Thursday, 19 December 2024 at 16:52:35 UTC, Atila Neves wrote:
>>> On Thursday, 6 June 2024 at 15:47:50 UTC, Timon Gehr wrote:
>>
>>>> [...]
>>
>>> I think we will just have to live with this and encourage people to upgrade to the newer edition.
>>
>> So using a library from a previous edition *could* invalidate memory safety guarantees, and nothing can be done?
>>
>> This is (again) a marketing disaster ...
>
> I'm all ears as to what we could do instead.

Refuse to compile previous editions @safe functions, if a bug related to memory safety was applied in following revisions.

At least provide a compiler switch to turn on this behavior, so that it's crystal clear to the programmer that's dealing with them.