Menu
Search

Forums

Forum Index

January 05, 2022
Gravatar of DennisPosted by Dennis
in reply to Atila Neves		Reply
Dennis
Gravatar of Dennis
Posted in reply to Atila Neves


Reply

On Wednesday, 5 January 2022 at 10:05:02 UTC, Atila Neves wrote:

>

I talked to Walter about this and I don't think it's the correct fix. I've been looking at how to do it otherwise.

Why not? Given a signature like:

int fun(string s) pure nothrow;

You can assume s is scope, because there's no channel to escape it: return value has no pointers, global variables are not accessible in a pure function, there are no other parameters to assign it to.

But when the signature is this:

int fun(string s) pure;

You can assign s to an Exception that gets thrown. How would you prevent / detect that?

January 07, 2022
Gravatar of Atila NevesPosted by Atila Neves
in reply to Dennis		Reply
Atila Neves
Gravatar of Atila Neves
Posted in reply to Dennis


Reply

On Wednesday, 5 January 2022 at 10:47:50 UTC, Dennis wrote:

>

On Wednesday, 5 January 2022 at 10:05:02 UTC, Atila Neves wrote:

>

I talked to Walter about this and I don't think it's the correct fix. I've been looking at how to do it otherwise.

Why not? Given a signature like:

int fun(string s) pure nothrow;

You can assume s is scope, because there's no channel to escape it: return value has no pointers, global variables are not accessible in a pure function, there are no other parameters to assign it to.

But when the signature is this:

int fun(string s) pure;

You can assign s to an Exception that gets thrown. How would you prevent / detect that?

You can, but it's likely that the vast majority of code won't. Changing this would break a lot of code, as seen by your attempts to fix Phobos.

Another option is making it so pure functions can't throw, but that also probably introduces a lot of breakage.

January 07, 2022
Gravatar of baussPosted by bauss
in reply to Atila Neves		Reply
bauss
Gravatar of bauss
Posted in reply to Atila Neves


Reply
On Friday, 7 January 2022 at 08:39:25 UTC, Atila Neves wrote:
>
> Another option is making it so pure functions can't throw, but that also probably introduces a lot of breakage.

It would be a somewhat correct approach, because while in theory you can throw from pure functions, then you violate the purity by observing the thrown exception.

So it doesn't really make much sense to throw in a pure function in itself, as using the exception will be a direct violation of purity.
January 07, 2022
Gravatar of DennisPosted by Dennis
in reply to Atila Neves		Reply
Dennis
Gravatar of Dennis
Posted in reply to Atila Neves


Reply

On Friday, 7 January 2022 at 08:39:25 UTC, Atila Neves wrote:

>

You can, but it's likely that the vast majority of code won't. Changing this would break a lot of code, as seen by your attempts to fix Phobos.

Another option ...

I don't see a first option in your first paragraph. "it's likely that the vast majority of code won't", sure, but scope inference needs to be 100%, 'likely scope' is not useful information for DMD.

>

Another option is making it so pure functions can't throw, but that also probably introduces a lot of breakage.

pure nothrow functions don't break, it's only pure functions that throw exceptions that lose their free scope inference. Disallowing pure throw functions entirely results in a strict superset of the breakage, on top of adding an arbitrary restriction to users.

January 07, 2022
Gravatar of DennisPosted by Dennis
in reply to bauss		Reply
Dennis
Gravatar of Dennis
Posted in reply to bauss


Reply
On Friday, 7 January 2022 at 08:46:27 UTC, bauss wrote:
> So it doesn't really make much sense to throw in a pure function in itself, as using the exception will be a direct violation of purity.

Printing the stack trace of an Exception can only happen when you catch it in an impure function. In that case the side effects happen there, that doesn't make the function that threw the Exception impure.

Catching the Exception in a `pure` function is not a violation either, whatever you do with the Exception object in the catch block is the same as what you could do if the Exception was returned instead of thrown.
January 08, 2022
Gravatar of DukcPosted by Dukc
in reply to Dennis		Reply
Dukc
Gravatar of Dukc
Posted in reply to Dennis


Reply

On Wednesday, 5 January 2022 at 10:47:50 UTC, Dennis wrote:

>

On Wednesday, 5 January 2022 at 10:05:02 UTC, Atila Neves wrote:

>

I talked to Walter about this and I don't think it's the correct fix. I've been looking at how to do it otherwise.

Why not? Given a signature like:

int fun(string s) pure nothrow;

You can assume s is scope, because there's no channel to escape it: return value has no pointers, global variables are not accessible in a pure function, there are no other parameters to assign it to.

There is one problem with this. The string could still be assigned to a non-Exception Throwable and thrown. If the function implementation is also @safe, the compiler is going to wrongly prevent throwing the exception due to the automatically added scope.

When you think of it, it means that asserts using s as the message would be forbidden. Or worse, they would be allowed but the assert failure printer would then try to access expired memory after such an assert has gone boom.

January 08, 2022
Gravatar of ElronndPosted by Elronnd
in reply to bauss		Reply
Elronnd
Gravatar of Elronnd
Posted in reply to bauss


Reply
On Friday, 7 January 2022 at 08:46:27 UTC, bauss wrote:
> It would be a somewhat correct approach, because while in theory you can throw from pure functions, then you violate the purity by observing the thrown exception.
>
> So it doesn't really make much sense to throw in a pure function in itself, as using the exception will be a direct violation of purity.

Exceptions can be modeled as return values. This is a strictly local rewrite.  So it is no more a violation of purity than is writing to memory pointed to by passed-in pointers (and arguably less).
January 08, 2022
Gravatar of DennisPosted by Dennis
in reply to Dukc		Reply
Dennis
Gravatar of Dennis
Posted in reply to Dukc


Reply

On Saturday, 8 January 2022 at 00:13:38 UTC, Dukc wrote:

>

There is one problem with this. The string could still be assigned to a non-Exception Throwable and thrown.

Yikes, that's another annoying oversight. I hope we don't have to do away with pure based scope inference entirely. Since Errors are only thrown once per program, it could be okay to make the assert handler's message string scope forcing it to copy it when it wants to back trace, but when throwing a custom Throwable class this is harder to enforce.

January 08, 2022
Gravatar of Nick TreleavenPosted by Nick Treleaven
in reply to Elronnd		Reply
Nick Treleaven
Gravatar of Nick Treleaven
Posted in reply to Elronnd


Reply
On Saturday, 8 January 2022 at 13:33:26 UTC, Elronnd wrote:
>
> Exceptions can be modeled as return values. This is a strictly local rewrite.  So it is no more a violation of purity than is writing to memory pointed to by passed-in pointers (and arguably less).

They can 'return' to a higher scope than the caller of the function. Any stack memory from the caller's frame will be corrupted. @safe cannot allow this.
January 08, 2022
Gravatar of Nick TreleavenPosted by Nick Treleaven
in reply to Nick Treleaven		Reply
Nick Treleaven
Gravatar of Nick Treleaven
Posted in reply to Nick Treleaven


Reply
On Saturday, 8 January 2022 at 18:19:47 UTC, Nick Treleaven wrote:
> @safe cannot allow this.

To be clear, I was talking about inferred scope parameters that actually escape via a throwable, not about throwing from pure functions.
« First   ‹ Prev
1 2
Next ›   Last »