[Issue 23124] [dip1000] scope inference leads to implementatio-defined semantics for @trusted and @system.

[d-bugmail at puremagic.com]

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

Ate Eskola <Ajieskola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |---
            Summary|[dip1000] scope and return  |[dip1000] scope inference
                   |should not be inferred for  |leads to
                   |@trusted function           |implementatio-defined
                   |                            |semantics for @trusted and
                   |                            |@system.

--- Comment #2 from Ate Eskola <Ajieskola at gmail.com> ---
I did change my mind in the topic a bit. I said previously, that no `scope`
inference should be done for a `@trusted` or `@system` function. Now I think
that it's okay, good even, to infer, but if the inference changes the
attributes it should be an error.

Why? Consider a hypothetical future spec-compliant D compiler. The language
spec does not say where the inference must stop, so our future compiler infers
`scope` only if the argument is directly returned. If it encounters any other
expression than a plain symbol name, it stops inference there.

Now we have a function
------
import std.random : dice;
auto either(int* a, int* b) @trusted { return dice(1,1) ? a : b; }
------

What happens? DMD infers arguments a and b as `scope`, BUT our future compiler
does not. What is a perfectly safe function with DMDFE just became a terrible
footgun in another spec-abiding compiler!

So, if we don't want to disable inference in these cases, there are two
options:

1: If inference detects need for adding `scope` or `return` to a `@system` or
`@trusted` function, it must error.

2: The spec must unambiguously specify where `scope` and `return scope` should
be inferred and where it should not.

I think the first option is simpler, but I'm happy with either one.

--