https://issues.dlang.org/show_bug.cgi?id=23124
Ate Eskola <[email protected]> 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 <[email protected]> --- 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. --
